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ABSTRACT 


The  Civil  Engineer  Corps  (CEC)  is  a  small  group  of  naval  officers  totaling 
approximately  1250  officers.  Being  a  small  community,  the  CEC  attempts  to  capture  the 
location  and  other  relevant  information  of  every  CEC  Officer  at  a  given  time  and  publish 
that  information  in  the  Chief  of  Civil  Engineers  Directory  (P-1).  The  CEC  detailers  also 
produce  and  work  off  a  Staffing  Plan  to  help  them  manage  the  movement  of  officers. 
The  current  process  of  developing  the  Staffing  Plan  and  P-1  is  complex  and  arduous. 

This  thesis  examines  existing  systems  at  the  CEC  detail  shop  and  explores  the 
possibilities  of  developing  a  Detailing  Management  System.  The  intent  is  to  develop  a 
prototype  application  that  links  with  existing  systems  to  assist  the  detailers  in  the 
execution  of  their  tasks  including  the  streamlined  production  of  the  P- 1  and  Staffing  Plan. 

A  prototyping  methodology  is  used  to  accomplish  these  goals.  The  methodology 
includes  the  following  phases:  Problem  Definition,  Requirements  Analysis,  Design, 
Build/Revise  prototype,  and  Finalize  application  The  build  phase  is  iterated  through 
several  end-user  reviews  to  obtain  the  best  possible  product  to  support  their  needs. 

The  completion  of  this  thesis  demonstrates  that  the  concept  of  a  detailing 
management  program  that  meets  the  needs  of  the  users  is  valid  and  must  be  addressed  in 
future  development  of  production  systems.  The  application  supports  the  immediate 
requirements  of  streamlining  the  development  of  the  Staffing  Plan  and  P-1  while 
providing  additional  detailing  management  capabilities. 
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I.  INTRODUCTION  &  BACKGROUND 


A.  AREA  OF  RESEARCH 

The  Civil  Engineer  Corps  (CEC)  is  small  group  of  naval  officers  accounting  for 
about  2.3%  of  the  total  officer  strength  in  the  United  States  Navy,  or  approximately  1250 
officers.  CEC  duty  assignments  are  generally  focused  in  three  main  areas:  Public  Works, 
Contracting,  or  Construction  Battalions  (Seabees).  These  duty  stations  can  be  located 
anywhere  in  the  world.  Being  a  small  community,  the  CEC  attempts  to  capture  the 
location  of  every  CEC  Officer  at  a  given  time  and  publish  that  information  in  the  Chief  of 
Civil  Engineers  Directory  (P-1).  The  P-1  contains  information  on  where  all  officers  in 
the  CEC  are  located,  what  their  billet  position  is,  and  when  they  reported  to  that 
particular  duty  station.  It  also  has  the  address  and  phone  numbers  of  each  command 
(activity)  where  the  CEC  has  personnel  stationed.  Many  CEC  Officers  use  the  P-1  to 
keep  in  contact  with  their  colleagues  and  to  search  for  openings  for  their  next  duty 
station,  based  on  their  projected  rotation  date  (PRD).  This  publication  is  printed  annually 
and  approximately  2000  copies  are  distributed  throughout  the  CEC  at  a  cost  of  around 
$12,000.  The  current  process  of  developing  the  P-1  is  a  complex  and  arduous  one,  which 
is  described  in  Chapter  2. 

A  new,  user-friendly  relational  database  system  will  greatly  facilitate  the 
production  of  the  P-1,  Staffing  Plan,  and  assist  the  CEC  detailers  in  the  accomplishment 
of  their  duties  by  giving  them  ready  access  to  information  displayed  in  a  logical  manner. 
A  system  which  is  either  linked  to  the  legacy  data  application  or  routinely  imports  the 
data  via  an  automated  process  will  decrease  the  burden  on  the  staff  to  produce  the  P-1 
and  Staffing  Plan  and  allow  them  to  focus  on  their  primary  mission  which  is  to  place 
CEC  officers  in  billets  matching  the  needs  of  the  navy,  individual,  and  the  individual’s 
career. 

B.  RESEARCH  ISSUES 

The  main  objective  of  this  thesis  is  to  examine  the  possibility  of  integrating  a 
new,  user-friendly  system  with  the  current  legacy  personnel  system.  The  research 
focuses  on  developing  an  appropriate  data  model  for  the  prototype,  taking  into  account 
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the  current  systems  and  the  requirements  of  the  CEC  Detail  Shop  (PERS  4413). 
Essential  to  the  process  of  developing  the  data  model  is  the  determination  of  which 
development  strategy  to  use:  top-down  or  bottom-up.  (Kroenke,  2000  pp.  41-42)  Top- 
down  development  is  a  global  approach  to  system  development.  It  starts  with  a  study  of 
an  organization’s  strategic  goals,  the  methods  by  which  those  goals  can  be  accomplished, 
the  information  that  is  required  to  meet  these  goals,  and  the  systems  necessary  to  provide 
that  information.  A  bottom- up  approach  works  in  the  reverse  order.  It  begins  with  the 
need  for  a  specific  system  and  builds  up  from  there.  Requirements  are  drawn  up  based 
on  existing  systems  and  reports  as  well  as  end-user  input  to  form  the  basis  for  the  design 
of  the  project.  Bottom- up  development  was  chosen  because  it  is  faster  and  smaller  in 
scope  than  a  top-down  approach,  which  can  many  times  lead  to  analysis  paralysis. 

Another  critical  issue  to  consider  is  which  design  methodology  should  be  used  for 
the  system.  Quick  development  and  limited  initial  interaction  with  the  end  users  of  the 
system  play  a  key  role  in  the  choice  of  design  methodology.  The  methodologies 
considered  were  a  classic  waterfall  approach,  a  prototype  approach,  and  a  spiral 
approach.  Prototype  approach  was  used  as  it  is  utilizes  a  complete  requirements  analysis 
up  front  and  iterative  design  and  build  phases. 

A  final  issue  that  is  critical  to  the  thesis  is  the  integration  of  the  legacy  system  into 
the  new  model.  The  issue  regarding  how  the  new  system  will  interact  with  the  legacy 
system  is  considered.  Options  include  linking  directly  to  the  system,  a  one-time 
migration  of  the  data  from  the  old  system  to  the  new  system,  or  an  import  routine  that  is 
done  each  time  the  user  wants  to  update  the  new  system.  The  legacy  system  situation  at 
PERS  4413  is  very  dynamic  and  the  solution  needs  to  be  flexible  to  meet  the  users’  needs 
for  the  future.  A  standalone  system  that  is  maintained  from  a  one-time  import  could  be 
ideal  if  the  users  are  diligent  in  maintaining  the  information  in  parallel  systems.  A  more 
in-depth  analysis  and  discussion  on  this  issue  is  discussed  in  Chapter  IV. 

C.  SCOPE 

The  primary  objective  of  this  thesis  is  to  provide  PERS  4413  with  a  user-friendly 
management  tool  that  will  link  with  or  import  from  the  legacy  personnel  system  to  assist 
in  the  production  of  the  P-1  and  Staffing  Plan  along  with  other  detailing  functions.  To 
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accomplish  this  goal,  the  work  will  be  split  up  into  two  parts.  The  first  part  is  the 
development  of  the  relational  data  model  and  database  application  that  captures  ah  the 
entities  currently  maintained  in  the  PERS  4413  legacy  systems  that  relate  to  the  CEC 
personnel  management  and  the  production  of  the  P-1.  Information  contained  in  the 
database  will  include,  but  not  be  limited  to,  personnel  data,  billet  information,  and 
activity  information.  The  remaining  portion  of  the  thesis  will  focus  on  how  the  new 
system  will  interact  with  the  legacy  application  and  its  data.  The  ease  of  data  transfer  and 
integration  for  the  user  is  a  key  part  of  the  success  of  the  project.  PERS  4413  intends  to 
use  the  new  application  primarily  for  the  production  of  the  P-1  and  Staffing  Plan.  Any 
additional  functionality  added  to  prototype  the  Detailing  Management  System  is  for 
academic  purposes  and  is  intended  to  demonstrate  the  increased  capability  of  a  relational 
database  application  vice  legacy  stovepipe  systems.  This  thesis  will  not  incorporate  the 
use  of  web  technologies  to  manipulate  or  display  information.  The  data  maintained  in 
this  project  contains  sensitive  Privacy  Act  information.  Therefore,  security  is  built  into 
the  application  to  allow  only  authorized  personnel  access  to  the  information. 

D.  METHODOLOGY 

Much  of  the  success  of  any  information  systems  project  depends  on  the 
appropriate  selection  and  execution  of  a  development  methodology.  In  order  to  select  a 
proper  methodology,  a  review  is  provided  below  for  three  popular  development 
methodologies.  A  methodology  is  an  organized,  documented  set  of  procedures  and 
guidelines  for  one  or  more  phases  of  the  systems  development  life  cycle  (SDLC)  that 
may  or  may  not  incorporate  the  use  of  several  development  tools  and  techniques.  The 
SDLC  is  a  logical  process  by  which  developers  and  end-  users  build  information  systems 
to  solve  business  problems  or  address  specific  needs.  (Whitten,  1998,  pp.  72-73)  The 
three  methodologies  that  were  considered  are  the  Waterfall,  Prototype,  and  Spiral 
approach.  These  methodologies  are  by  no  means  an  all-inclusive  list  of  possibilities,  but 
are  three  of  the  most  popular  in  the  industry  today.  Each  one  of  these  methodologies  will 
be  evaluated  on  their  strengths,  weaknesses,  and  implied  risks.  For  this  thesis,  I  chose  to 
follow  the  prototyping  methodology.  A  more  detailed  explanation  of  each  of  these 
methodologies  and  the  reason  for  selecting  the  prototype  is  located  in  Chapter  II. 
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E.  ORGANIZATION 

This  thesis  will  be  organized  in  the  following  manner: 

•  Chapter  II  further  defines  the  problem,  identifies  stakeholders, 
defines  the  scope,  and  examines  the  feasibility  of  the  project. 

•  Chapter  III,  the  requirements  analysis,  is  the  natural  follow  on  to 
the  problem  definition  and  defines  what  the  end-users  require  to 
perform  their  job.  The  data  requirements  and  application 
requirements  are  examined  thoroughly.  Any  required  reports  or 
existing  reports  being  used  by  PERS  4413  will  be  collected  and 
analyzed  to  complete  the  model  definition 

•  Chapter  IV  gives  an  overview  of  standard  design  philosophies 
adhered  to  in  this  thesis.  Database  design  issues  as  well  as 
application  design  issues  are  discussed  in  depth. 

•  Chapter  V  discusses  the  actual  development  of  the  application  with 
specific  attention  to  structure  and  the  graphical  user  interface 
(GUI).  Prototyping  is  discussed  as  well  as  the  training  and 
implementation  plans. 

•  Chapter  VI  addresses  what  to  do  after  implementation.  It  discusses 
how  the  system  is  to  be  maintained,  including  both  data  and 
application  maintenance  as  well  as  scalability.  Human  resource 
requirements  and  ongoing  training  are  also  addressed. 

•  Chapter  VII  summarizes  the  project  and  reviews  lessons  learned,  in 
addition  to  recommending  areas  of  future  study. 

F.  BENEFITS 

One  of  the  Navy’s  greatest  resources  is  its  personnel.  To  maximize  the 
effectiveness  of  the  CEC  community,  the  CEC  detailers  need  an  efficient,  user-friendly 
tool  to  help  plan  and  program  personnel  movements.  This  research  will  have  an 
immediate  impact  on  the  PERS  4413  personnel  by  enabling  them  to  quickly  access 
information  that  was  previously  inaccessible  without  a  tremendous  effort.  It  also 
provides  insight  on  the  issues  faced  when  dealing  with  legacy  stovepipe  applications, 
helping  the  Navy  to  perhaps  avoid  the  same  mistakes  in  the  future. 
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H.  INITIATION  &  PLANNING 


A.  METHODOLOGY  SELECTION 

As  discussed  in  Chapter  I,  methodology  selection  can  play  a  very  important  role 
into  how  a  project  will  evolve  and  ultimately  how  much  success  it  will  have.  The  three 
methodologies  considered  for  this  thesis  are  described  below. 

1.  Waterfall  Model 

The  waterfall  model  describes  a  development  method  that  is  linear  and  sequential. 
Waterfall  development  has  distinct  goals  for  each  phase  of  development,  that  once 
completed  are  not  revisited.  In  other  words,  once  a  phase  of  development  is  completed, 
the  development  proceeds  to  the  next  phase  and  there  is  no  turning  back.  A  graphical 
representation  of  the  waterfall  approach  can  be  seen  in  Figure  1. 
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Figure  1.  Waterfall  Methodology 


5 


a.  Strengths 

•  Each  step  is  verified  and  validated  prior  to  moving  to  the 
next. 

•  Clear  definition  of  requirements  up  front  help  to  focus  the 
project  on  necessary  elements. 

b.  Weaknesses 

•  Changes  in  requirements  during  development  can  be  very 
costly. 

•  There  is  no  working  product  prior  to  completion;  therefore, 
problems  in  any  of  the  phases  will  not  surface  until  the  end 
of  the  program. 

•  It  does  not  allow  for  much  reflection  or  revision 

c.  Implied  Risks 

•  If  the  requirements  are  not  well  defined,  the  project  could 
be  in  jeopardy. 

•  Changes  during  development  could  greatly  increase  costs 
and  time. 

2.  Prototyping  Model 

The  prototyping  model  is  a  methodology  in  which  a  prototype  is  built,  tested,  and 
then  reworked  as  necessary  until  an  acceptable  prototype  is  finally  achieved  from  which 
the  complete  system  or  product  can  now  be  developed.  This  model  works  best  in 
scenarios  where  not  all  of  the  project  requirements  are  known  in  detail  ahead  of  time.  It  is 
an  iterative,  trial- and- error  process  that  takes  place  between  the  developers  and  the  users. 
A  graphical  representation  of  the  prototype  methodology  can  be  seen  in  Figure  2. 
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Figure  2.  Prototype  Methodology 


a.  Strengths 

•  Gives  early  capability  in  the  project. 

•  Build  and  test  as  you  go  -  allows  the  team  to  tst  the 
product  modules  with  existing  infrastructure  and  make 
changes  as  you  go. 

•  Encourages  and  requires  active  end-user  participation. 

•  Gives  the  end-users  an  opportunity  to  provide  direction  for 
the  application  design,  which  provides  them  with  a  sense  of 
ownership. 

•  Users  will  be  more  responsive  and  helpful  if  they  have 
something  to  touch  and  feel  as  opposed  to  a  diagram  to 
look  at. 

•  Can  increase  creativity  because  it  allows  for  quicker  user 
feedback,  which  can  lead  to  better  solutions. 

b.  Weaknesses 

•  If  the  requirements  are  not  properly  defined,  the  project 
timeline  could  be  delayed  and  costs  could  increase. 

•  Product  modules  could  be  split  up  incorrectly  based  on 
invalid  assumptions  and  assessments. 

•  Can  encourage  ill-advised  shortcuts  through  the  life  cycle. 
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•  Often  leads  to  a  premature  commitment  to  a  design. 

•  Susceptible  to  “feature  creep”  where  the  scope  and 
complexity  of  the  system  can  expand  beyond  original  plans 
quickly. 

•  Can  also  reduce  creativity  in  certain  areas.  A  user  and 
designer  who  view  a  prototype  report  can  become 
entrenched  in  that  design  for  the  report,  unable  to  see  other 
options. 

c.  Implied  Risks 

•  Too  much  testing  can  slow  the  project  down.  Clear  testing 
milestones  need  to  be  set. 

•  All  functions  and  requirements  must  be  defined  and 
understood  up  front  to  prevent  a  never-ending  cycle. 

3.  Spiral  Model 

The  spiral  model  is  a  development  methodology  which  combines  the  features  of 
the  prototype  model  and  the  waterfall  model  The  spiral  model  is  generally  favored  for 
large,  expensive,  and  complicated  projects.  A  graphical  representation  of  the  spiral 


methodology  can  be  seen  in  Figure  3. 
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a.  Strengths 

•  Brings  early  capability  to  the  project. 

•  Any  unforeseen  or  additional  requirements  are  more  easily 
and  cheaply  incorporated. 

b.  Weaknesses 

•  Difficult  to  set  and  stick  to  a  budget  when  requirements  and 
scope  are  continually  developed  as  the  project  progresses. 

•  When  does  the  spiral  end?  This  type  of  project  has  the 
potential  for  continual  development  with  no  clear  end. 

c.  Implied  Risks 

•  Involves  gathering  many  individuals  together  at  multiple 
times.  This  alone  could  be  a  major  obstacle. 

•  Obtaining  user  feedback  (not  upper  management)  is  vital  to 
the  success  of  the  project. 

In  addition  to  the  methodologies  described  above,  there  are  numerous  others  that 
are  being  used  in  all  facets  of  information  technology  development.  Some  methodologies 
are  a  blend  of  others  and  new  ones  are  created  continually  because  every  project  has 
specific  needs  that  one  particular  methodology  may  not  meet. 

For  this  thesis,  I  chose  to  utilize  the  prototyping  approach  for  several  reasons: 

•  The  requirements  analysis  is  done  in  one  visit,  saving  time  and  travel  costs 

•  Getting  all  the  requirements  in  one  trip  is  unlikely  -  multiple  prototypes 
will  help  flush  out  the  remaining  requirements. 

•  The  build  phase  is  iterated  and  reviewed  by  the  end-user  to  achieve  the 
best  possible  product. 


B.  IDENTIFY  STAKEHOLDERS 

Seeking  out  and  identifying  key  stakeholders  in  any  project  is  critical  to  its 
success.  Stakeholders  can  be  anyone  that  has  a  vested  interest  in  the  existing  systems 
being  analyzed,  the  new  system  being  proposed,  or  anyone  who  controls  the  purse  strings 
of  the  budget  that  will  be  used  for  the  project.  These  stakeholders  can  range  from  the 
Commanding  Officer  who  wants  to  see  an  improved  system  for  any  number  of  reasons  to 
the  end-user  who  interacts  with  the  system  on  a  daily  basis.  Other  stakeholders  could 
include  the  information  systems  support  staff,  chief  financial  officers,  or  any  other 
interested  party  that  may  have  influence  on  the  project. 
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LT  Neil  Rader  and  I  conducted  an  initial  discovery  trip  in  June  2001  for  the 
purpose  of  reviewing  existing  systems,  identifying  stakeholders,  and  determining 
feasibility.  At  the  time,  the  scope  of  the  project  was  envisioned  to  be  a  much  larger 
enterprise  that  would  have  included  full  internet  capability  along  with  the  database 
application.  A  complete  copy  of  the  trip  report  for  this  visit  can  be  found  in  Appendix  B. 
During  this  trip,  several  stakeholders  were  identified  and  interviewed,  producing  the 
following  information. 

1.  CEC  Detailers 

a.  PERS  4413  Head  Detailer/Community  Manager 

The  head  detailer  is  responsible  for  the  overall  management  of  the  CEC 
community  and  specifically  handles  all  the  personnel  detailing  for  those  officers  who 
hold  the  rank  of  Captain  and  above.  He  also  is  the  final  approving  authority  for  budget 
spending  on  this  project.  He  was  not  available  for  specific  interviews  during  the 
discovery  trip  as  it  was  his  first  week  in  that  position,  but  did  endorse  the  conceptual  idea 
of  the  project  to  a  certain  extent.  His  main  concern  was  that  the  project  would  result  in 
something  easier  for  the  Community  Management  Analyst  to  use  in  the  preparation  of  the 
P- 1  and  Staffing  Plan.  Little  to  no  interest  was  expressed  in  a  detailing  management  tool 
for  the  rest  of  the  detailers  to  use  in  addition  to  the  other  systems  they  were  using  at  the 
time. 

b.  PERS  441 3 A  LCDR  Detailer 

The  LCDR  detailer  is  typically  a  CDR  and  handles  all  the  detailing  needs 
for  CEC  personnel  that  hold  the  rank  of  LCDR.  He  works  closely  with  the  head  detailer 
and  also  with  the  LT  detailer  to  fill  any  billet  gaps  with  junior  or  senior  officers.  During 
his  interview,  he  expressed  that  his  main  concern  was  streamlining  the  production  of  the 
P-1  and  Staffing  Plan.  Anything  beyond  that  he  was  not  concerned  with  at  all.  He 
routinely  pulled  data  down  from  the  Officer  Data  Information  System  (ODIS)  to  manage 
the  personnel  under  his  responsibility.  He  would  download  the  data  and  import  it  into  an 
MS  Excel  spreadsheet  and  manipulate  it  from  there  (see  example  in  Appendix  C).  He 
would  sort  the  spreadsheet  by  rotation  date  to  see  who  was  due  to  change  duty  stations 
and  then  added  about  7  fields  that  he  used  to  plug  names  in  of  the  people  he  was  thinking 
about  placing  in  that  billet.  He  would  then  juggle  these  names  around  to  find  the  best  fit 
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based  on  balancing  the  needs  of  the  Navy,  career  needs  of  the  individual,  and  desires  of 
the  individual.  He  would  also  sort  these  lists  in  other  manners  such  as  from  the  senior 
LCDR  to  most  junior  LCDR  in  the  promotion  zone  to  get  an  idea  on  whether  he  should 
wait  to  issue  orders  depending  on  if  the  officer  was  selected  for  promotion  or  not.  He 
also  examined  the  billet  list  sorted  by  type  of  position.  In  addition  to  these  spreadsheets, 
he  also  logged  every  phone  conversation  and  email  correspondence  that  he  had  with  a 
member  using  MS  Outlook’s  Journal  feature. 

c.  PERS  4413E  LT/CWO/Grad  School  Detailer 

The  LT  detailer  is  also  in  charge  of  sending  CEC  personnel  to  graduate 
school  and  detailing  the  Chief  Warrant  Officers  to  their  respective  billets.  Similar  to  the 
LCDR  Detailer,  he  works  closely  with  the  detailers  above  and  below  him  to  fill  any  billet 
gaps.  During  his  interview,  he  was  most  receptive  to  a  tool  that  would  consolidate  all  the 
information  that  he  spends  hours  collating  just  to  get  a  simple  report.  He  was  most 
interested  in  being  able  to  sort  a  list  of  personnel  by  a  multitude  of  factors  such  as  year 
group,  rank,  promotion  status,  etc.  Another  useful  tool  that  he  would  like  to  see  is  the 
capability  to  show  only  those  billets  that  require  a  certain  qualification,  such  as  Seabee 
Combat  Warfare  pin.  Other  nice  to  have  reports  were  a  duty  history  for  each  member,  a 
billet  history,  and  the  ability  to  filter  billets  by  type  such  as  Public  Works,  ROICC,  staff, 
or  Seabees,  etc.  He  did  most  of  his  detailing  off  the  Staffing  Plan,  but  also  used  a 
spreadsheet  system  similar  that  was  slightly  different  from  the  LCDR  detailer.  His 
spreadsheet  (example  shown  in  Appendix  C)  contained  information  on  the  member  and 
could  be  sorted  in  various  manners.  He  also  added  several  fields  on  the  end  for  his  own 
use  in  placing  the  member’s  preferences  and  any  other  additional  comments  he  may  have 
on  the  particular  member. 

d.  PERS  4413C  LTJG/ENS  Detailer 

The  LTJG/ENS  detailer  is  typically  a  LT  and  handles  all  the  assignments 
for  the  junior  officers  of  the  CEC.  He  is  responsible  for  each  officer’s  first  duty 
assignment  in  the  CEC  and  also  handles  the  Naval  Mobile  Construction  Battalion 
(NMCB)  detailing.  The  interview  with  the  LTJG/ENS  detailer  revealed  that  in  this 
office,  like  most  other  offices  in  the  military,  the  junior  man  gets  to  do  a  lot  of  the  grunt 

work  for  the  other  senior  members  of  the  office.  In  addition  to  performing  his  own  data 
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pulls  from  the  system,  he  also  did  data  pulls  for  the  other  detailers  as  well.  Again,  like 
the  other  detailers  he  used  a  spreadsheet  to  keep  track  of  the  personnel  and  billets  under 
his  responsibility.  His  spreadsheet  was  amilar  to  the  others  with  respect  to  the  data 
elements  contained  (see  Appendix  C),  but  his  method  of  using  it  was  slightly  different. 
He  relied  mostly  on  color-coding  of  information.  Purple  rows  were  for  students  at  the 
Civil  Engineer  Corps  Officer  School  (CECOS),  red  rows  indicated  proposed  orders, 
orange  were  approved,  awaiting  orders,  and  blue  were  reserved  for  those  personnel  to 
whom  he  had  guaranteed  a  particular  duty  station.  Additionally,  he  kept  a  paper  log  of 
phone  conversations  that  he  had  with  any  service  members.  He  also  filled  in  when 
needed  to  write  orders  when  the  Community  Management  Analyst  was  not  available  to 
do  them. 

e.  PERS  4413S  CEC  Community  Management  Analyst 

The  CEC  Community  Management  Analyst  is  the  heart  and  soul  of  the 
organization.  He  is  a  civilian  worker  that  provides  continuity  amongst  the  constant 
rotation  of  officers  in  the  detail  shop.  He  is  also  the  information  hub  where  all  the 
corporate  knowledge  resides.  He  provides  assistance  to  the  detailers  regarding  all  aspects 
of  the  business  and  is  the  resident  expert  in  the  use  of  the  information  systems 
applications  provided  for  the  detailers.  He  is  responsible  for  the  production  of  the  P-1 
and  the  Staffing  Plan  and  the  only  one  who  knows  how  to  use  the  current  system  to 
produce  the  plans.  He  is  also  the  chief  order  writer  for  the  detailers.  During  this 
discovery  trip,  most  of  our  time  was  spent  with  him  as  he  walked  us  through  the  process 
of  creating  the  P- 1  and  Staffing  Plan.  As  mentioned  in  Chapter  I,  this  process  is  a  long 
and  complex  one  that  involves  numerous  steps  and  requires  considerable  corporate 
knowledge  of  the  CEC  community.  The  following  steps  are  a  synopsis  of  the  current 
process  for  producing  the  P- 1  and  the  Staffing  Plan: 

•  Two  separate  downloads  of  delimited  text  files  for  personnel  (bodies)  and 
job  positions  (billets).  See  Appendix  D  for  a  sample  of  these  files. 

•  Each  of  these  files  is  then  imported  into  a  Microsoft  Excel  spreadsheet. 
See  Appendix  E  for  a  sample  of  these  spreadsheets. 

•  The  spreadsheet  is  examined  and  manipulated  by  hand  to  correct  for  any 
data  anomalies  that  include,  but  are  not  limited  to: 
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•  Personnel  that  do  not  belong  in  the  database,  but  have  been  incorrectly 
identified  as  belonging  to  the  CEC. 

•  Reserve  billets  that  are  not  included  in  the  P-1. 

•  PEP  billets  that  are  not  used. 

•  Billet  sequence  code  (BSC)  errors. 

•  Prioritization  of  personnel  qualifications. 

•  Modification  of  billet  titles  and  rank  descriptions. 

•  Once  all  modifications  have  been  made,  the  Excel  file  is  imported  into  a 
Microsoft  Access  database  for  further  validation  and  manipulation.  The 
database  checks  for: 

•  Billets  without  any  matching  activities 

•  Duplicate  names  in  the  personnel  report 

•  Missing  names  in  the  personnel  report 

•  Billets  not  showing  up  in  the  billets  report 

•  Once  all  of  these  validations  are  complete,  the  P-1  is  ready  to  be 
generated.  A  button  is  pushed  and  approximately  100  macros  are  sent  into 
action  performing  magic  behind  the  curtain  to  produce  the  P- 1 . 

•  The  entire  process  takes  about  8  hours  to  accomplish  assuming  there  arc 
not  any  data  problems  or  computer  crashes. 

After  interviewing  all  of  the  detailers,  it  became  clear  that  each  detailer  operated 
using  the  same  data,  but  in  a  slightly  different  matter.  There  seem  to  be  similar  business 
models  for  each  detailer,  but  each  varies  slightly  from  the  other.  Further  analysis  would 
be  required  to  standardize  the  detailers  in  a  business  process  that  works  for  all  of  them. 
Once  that  is  done,  the  application  could  be  enhanced  to  meet  their  needs. 

2.  NAVPERSCOM  Information  Systems  Personnel 

NAVPERSCOM  is  currently  undertaking  many  IT  related  projects  including,  but 
not  limited  to,  NMCI,  legacy  systems  upgrades,  and  an  upgrade  to  the  EMPRS  system. 
There  is  a  local  development  project  underway  Single  Integrated  Human  Resource 
Strategy  -  SIHRS)  which  is  supposed  to  combine  all  the  stovepipe  systems  into  one 
relational  model  for  use  by  NAVPERSCOM.  The  systems  described  above  are  all 
planned  to  be  included  in  this  local  project  along  with  other  systems  not  mentioned. 
There  is  currently  no  timeframe  for  the  execution  of  this  project  and  it  is  understood  to  be 

just  in  the  conceptual  phase,  which  leads  to  the  estimation  that  the  successful  completion 
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of  this  project  is  at  least  5  years  away.  There  is  also  a  project  underway  at 
NAVPERSCOM  to  try  to  make  these  management  systems  entirely  web  based.  DOD  is 
also  examining  the  possibility  of  developing  the  Defense  Integrated  Human  Resource 
System  (DIMHRS),  which  is  intended  to  be  a  personnel  management  application  for  the 
entire  military.  It  is  not  known  whether  these  two  projects  will  be  integrated,  superceded, 
or  separated.  Given  the  number  and  magnitude  of  the  projects  that  NAVPERSCOM  is 
undertaking,  they  expressed  great  concern  in  allowing  another  system  to  be  created  to 
support  PERS  4413  outside  the  realm  of  their  oversight. 

C.  REVIEW  OF  CURRENT  SYSTEMS 

1.  Database  Systems  Background 

Prior  to  discussing  the  current  systems,  it  is  important  to  note  the  differences 
between  file-processing  systems  and  database  systems.  File  processing  systems  predated 
modem  relational  database  systems.  While  they  are  a  great  improvement  over  manual 
record-keeping  systems,  they  have  several  disadvantages  (Kroenke,  pp  11-13): 

•  Data  are  separated  and  isolated.  For  example,  in  the  case  of  the 
NAVPERSCOM  systems  there  are  two  files.  One  file  is  for  billets  and  the 
other  is  for  bodies.  These  two  files  are  completely  separate  from  each 
other  and  it  takes  programming  or  manual  manipulation  to  figure  out  what 
person  (body)  is  attached  to  what  billet. 

•  Data  are  often  duplicated.  In  this  same  case,  both  the  billets  and  the 
bodies  files  contain  the  same  information  on  UIC,  BSC,  Billet  Rank,  etc. 
In  fact,  matching  the  UIC  and  BSC  for  each  record  in  both  the  files  is  the 
only  way  to  figure  out  who  is  attached  to  what  billet. 

•  Application  programs  are  dependent  on  file  formats.  Most  file-processing 
systems  are  programmed  to  access  the  data  in  a  certain  format.  If  the 
format  changes  for  one  system,  then  all  other  systems  using  that  file  must 
be  reprogrammed  to  match  that  change.  For  example,  if  the  BSC  field  in 
the  billets  file  were  to  change  from  five  digits  to  seven  digits,  all  programs 
using  that  file  would  have  to  be  changed  to  match  the  new  format. 

•  Files  are  often  incompatible  with  one  another.  The  billets  file  comes  from 
OAIS  and  the  bodies  file  comes  from  OPINS.  The  OAIS  application 
cannot  read  the  bodies  file  and  the  OPINS  application  cannot  read  the 
billets  file.  A  separate  application  (ODIS)  was  created  to  combine  the  two 
files  and  present  the  information  in  one  application.  (Kroenke,  pp  11-13) 

Relational  database  systems  were  developed  to  overcome  the  limitations  of  file¬ 
processing  systems.  Databases  are  essentially  a  collection  of  interrelated  files.  The 
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records  in  each  file  must  allow  for  relationships  to  the  records  in  other  files.  These 
systems  have  great  advantages  over  file- processing  systems: 

•  Data  are  integrated.  All  the  application  data  is  stored  in  a  single  database. 
Each  table  (or  file)  in  the  database  is  uniquely  identified  by  a  field  called 
the  primary  key.  Tables  are  related  to  each  other  by  placing  one  table’s 
primary  key  into  another  table.  This  key  is  called  a  foreign  key. 

•  Reduced  data  duplication.  In  the  example  given  above,  instead  of  the  billet 
information  being  stored  with  both  the  person  and  the  billet,  the  UIC  and 
BSC  would  be  stored  only  in  with  the  billet.  Because  data  are  stored  in 
only  one  place,  data  integrity  problems  are  less  common. 

•  Program/Data  Independence  -  Database  processing  reduces  the 
dependency  of  programs  on  file  brmats.  The  formats  are  stored  along 
with  the  data  inside  the  database  and  are  accessed  by  the  Database 
Management  System  (DBMS),  not  the  application  program.  (Kroenke,  pp 
14-15) 

The  main  criticism  of  relational  databases  has  traditionally  been  performance. 
Relational  databases  require  more  computer  processing  power  than  its  predecessors.  This 
issue  has  virtually  disappeared  with  the  great  advancements  in  processing  power  of  the 
modem  computer. 

2.  Current  Systems  at  NAVPERSCOM 

Based  on  the  initial  discovery  trip,  a  basic  understanding  of  the  existing  systems 
being  used  was  achieved.  The  diagram  below  in  Figure  4  shows  the  current  system 
architecture. 
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Figure  4.  Current  System  Architecture 


The  master  file  for  the  Navy  (OPINS)  is  maintained  on  a  large  mainframe  bcated 
in  Cleveland,  OH.  The  locally  maintained  mainframe  (OAIS)  handles  the  day-to-day 
operations  for  personnel  management.  The  personnel  in  the  detail  shop  make  any 
changes  concerning  personnel  or  billets  in  this  system.  OAIS  and  OPINS  perform 
nightly  transaction  updates  to  synchronize  the  information.  When  a  staff  member  needs 
to  extract  information  to  create  reports  or  spreadsheets  to  perform  their  duties,  this  data  is 
taken  from  the  On-Line  Distribution  System  (ODIS)  in  ASCII  format.  The  ASCII  data  is 
downloaded  in  a  delimited  format  and  imported  into  Microsoft  Excel  for  manipulation 
and  reporting.  After  manipulation  in  Excel,  the  data  is  then  imported  into  the  current  P-1 
Database  to  produce  the  Staffing  Plan  and  the  P-1.  The  Electronic  Military  Personnel 
Record  System  (EMPRS)  is  a  separate  application  that  the  detailers  use  to  view  their 
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constituents’  digital  records  during  the  detailing  process.  The  four  systems  represented 
here  are  all  stovepipe  mainframe  applications  that  do  not  relate  to  each  other  except  in  a 
nightly  transaction-oriented  process  for  synchronization  of  data. 

One  year  after  this  initial  visit,  it  was  discovered  that  there  is  a  relational  database 
model  that  contains  a  large  amount  of  the  data  from  these  systems  at  NAVPERSCOM. 
This  database  is  called  the  Navy  Personnel  Database  (NPDB).  This  development  sparked 
a  change  in  the  data  migration  plan.  Instead  of  creating  a  data  import  routine  that  would 
import  the  ASCII  files,  a  read-only  view  of  the  required  data  elements  could  be  created 
that  to  link  to  the  new  database.  This  view  can  be  custom  created  to  match  the 
requirements  of  the  data  model  and  save  considerable  time  in  the  development  of  the 
application.  This  link  will  reduce  the  complexity  of  operation  for  the  end-  user  and  thus 
save  the  detailers  time  as  well.  As  time  continued  on  in  the  development  of  this  thesis,  it 
became  apparent  that  an  approval  to  link  with  this  data  would  come  in  time  to  complete 
the  thesis.  Development  quickly  switched  back  to  the  original  plan  of  importing  the  data 
from  the  delimited  text  files  and  further  manipulating  it  from  there.  Future  plans  for  this 
application  should  ensure  a  link  is  made  to  the  existing  production  systems  to  enhance  the 
usability  of  the  application  and  the  accuracy  of  the  data. 

3.  Define  Current  Problems  and  Constraints 
a.  Existing  Access  Database 

The  current  database  essentially  a  collection  of  spreadsheets  and  macros 
that  miraculously,  although  inefficiently,  produce  the  P-1  and  Staffing  Plan.  The  P-1  is 
only  updated  twice  a  year  because  the  task  is  so  arduous.  It  is  published  to  the  Civil 
Engineer  Corps  secure  server  for  viewing  on  the  Internet. 

The  existing  Microsoft  Access  database  that  is  being  used  for  the  creation 
of  the  P-1  and  Staffing  Plan  contains  43  tables,  none  of  which  has  primary  keys  or 
established  relationships.  As  explained  previously,  this  type  of  data  can  be  very 
dangerous  because  it  allows  for  the  duplication  of  data  and  potential  data  integrity 
problems.  If  two  tables  contain  a  member’s  name  and  location  but  differ  in  the  location, 
which  table  is  the  correct  one?  This  is  the  inherent  problem  with  stovepipe  systems  that 
do  not  relate  to  each  other. 
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The  application  also  contains  105  queries  and  100  macros.  A  macro  is  a 
saved  sequence  of  commands  or  keyboard  strokes  that  can  be  stored  and  then  recalled 
with  a  single  command  or  keyboard  stroke.  In  this  case,  the  macros  execute  a 
combination  of  queries  and  other  macros  to  create  relationships  and  match  the  billets  to 
bodies,  etc.  The  daisy  chain  of  commands  that  are  executed  when  producing  the  P-1  and 
Staffing  Plan  are  so  numerous  and  complex  that  even  a  skilled  database  administrator  and 
programmer  would  have  a  hard  time  following.  This  setup  makes  it  very  difficult  to 
troubleshoot  any  problems  that  may  occur  during  the  generation  of  the  P- 1  and  Staffing 
Plan.  As  a  general  rule,  macros  should  be  reserved  for  either  capturing  keystrokes  or 
carrying  out  a  series  of  actions  when  opening  an  Access  database.  In  the  place  of  macros, 
VBA  should  be  used  because  of  its  many  advantages: 

•  VBA  can  trap  and  handle  errors  where  macros  cannot. 

•  VBA  executes  faster  than  macros,  making  the  database 
performance  more  efficient. 

•  VBA  is  more  portable  than  macros.  If  you  want  to  move  a  form 
into  another  database,  the  VBA  code  automatically  goes  with  it. 
With  macros,  you  would  have  to  find  the  specific  macros  that  you 
needed  to  take  as  well. 

•  VBA  gives  you  more  flexibility  and  programmatic  control  where 
macros  can  only  carry  out  a  limited  set  of  instructions. 

b.  Data  Cleansing  Problems 

As  with  most  transitions  to  a  new  system,  data  cleansing  is  always  an 
issue.  As  previously  outlined,  there  are  several  issues  with  the  existing  data  set  that  must 
be  addressed  each  time  the  P-1  and  Staffing  Plan  are  created.  Appendix  F  is  the  page 
from  the  original  user’s  manual  for  the  current  system  and  outlines  what  particular  data 
elements  must  be  modified  or  deleted  prior  to  creating  the  plans.  Some  of  this  data  is 
simply  erroneous  data  in  the  legacy  system  that  could  be  fixed  by  requesting  the  changes 
through  proper  channels.  In  the  interview  with  the  Community  Management  Analyst,  he 
indicated  that  past  attempts  to  request  these  changes  were  ineffective.  He  now  just  lives 
with  the  current  anomalies  and  fixes  them  when  he  does  the  reports.  Much  of  these 
corrections  can  be  automated  as  they  follow  simple  rules,  but  there  are  some  that  can  only 
be  done  manually.  For  example,  any  personnel  that  come  through  the  system  that  have  a 
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rank  of  Commander  or  above  and  a  designator  of  5105  are  automatically  deleted  because 
they  are  reservists  who  are  not  tracked  by  this  office.  Below  the  rank  of  Commander, 
there  are  many  active  duty  CEC  Officers  who  still  have  a  designator  of  5105  and  the  only 
way  to  know  which  ones  belong  in  the  system  is  through  corporate  knowledge.  The 
Community  Management  Analyst  knows  all  the  active  CEC  Officers  and  can  pick  out  the 
ones  that  do  not  belong.  This  is  something  that  cannot  be  automated  and  must  be  set  up 
for  the  Community  Management  Analyst  to  check  using  traditional  manual  methods. 
The  new  database  automates  the  data  cleansing  wherever  possible  and  has  several  forms 
for  the  manual  cleansing  that  is  necessary.  Even  after  this  manual  cleansing,  there  is  no 
guarantee  that  the  data  will  be  correct.  The  crux  of  the  problem  is  that  PERS  4413  is 
trying  to  apply  a  different  business  model  to  the  legacy  systems.  These  systems  do  not 
support  the  way  the  CEC  detailers  want  to  do  business.  Because  of  this,  they  have  to 
create  workarounds  to  get  the  job  done.  Chapter  VI  addresses  in  detail  how  the  challenge 
of  importing  and  cleansing  the  data  as  well  as  relating  the  data  to  the  proper  entities  was 
accomplished. 

4.  Define  Future  Objectives 

The  objectives  of  this  database  application  are  two-tiered.  The  first  tier  will  meet 
the  requirements  of  the  CEC  Detail  Shop  by  providing  a  quick,  easy  to  use  application 
that  imports  the  legacy  system  data  and  produces  the  P- 1  and  Staffing  Plan.  This  is  the 
only  deliverable  that  they  are  looking  for.  The  second  tier  will  meet  the  thesis 
requirements  by  expanding  database  application  features  to  include  a  prototype  detailing 
management  system.  In  this  application,  the  user  will  be  able  to  move  personnel  from 
one  duty  station  to  another.  They  will  also  be  able  to  add,  update,  and  delete  all  the 
background  data  as  well  as  personnel  and  billet  information.  Additional  useful  reports 
will  be  created  as  well  as  areas  to  put  a  service- member’s  duty  preferences. 

5.  Project  Scope  Definition 

The  project  scope  will  include  the  following: 

•  Data  import  feature  to  bring  in  the  two  delimited  files  from  ODIS 

•  Automated  data  cleansing  routines  to  take  care  of  known  data  problems 

•  Manual  review  and  manipulation  of  imported  data 
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•  Data  management  tools  to  maintain  background  information  such  as 
qualification  codes,  designator  codes,  etc 

•  Easy  to  use  forms  for  updating  activity,  billet,  and  member  information 

•  P-1  and  Staffing  Plan  reports 

•  Other  reports  deemed  useful 

The  project  scope  will  not  include  the  following: 

•  P-1  and  Staffing  Plan  reports  in  the  exact  format  that  they  currently  exist 
in 

•  Real-time  link  to  existing  production  systems 

•  Web  interface 

D.  FEASIBILITY 

1.  Hardware  and  Software  Requirements 

The  hardware  and  software  requirements  for  this  system  are  in  line  with  current 
IT- 21  and  industry  standards.  The  application  will  be  developed  using  Microsoft  Access 
2002  but  saved  in  the  Microsoft  Access  2000  format.  Since  this  application  has  only  one 
user,  there  is  not  a  need  for  a  centralized  server  to  host  the  application.  The  host 
computer  that  the  application  will  reside  on  should  be  at  least  a  Pentium  III,  700  MHz 
computer  with  a  minimum  memory  requirement  of  128  MB  and  1  GB  of  free  hard  drive 
space.  Computers  that  do  not  meet  these  standards  may  experience  degradation  in 
performance  of  the  database  application  resulting  in  frustration  and  possibly  application 
errors. 

2.  Cost  Benefit  Analysis 

The  costs  for  this  project  are  broken  out  into  three  options: 

•  Do  nothing 

•  Hire  a  contractor 

•  Utilize  a  NPS  student 
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A  rudimentary  cost  analysis  is  presented  in  Table  1  below: 


Do  Nothing 

Hire  Contractor 

NPS  Student 

Hardware 

$0.00 

$0.00 

$0.00 

Software 

$0.00 

$0.00 

$0.00 

Labor  (320  hours  @  $200/hr) 

$0.00 

$64,000.00 

$0.00 

Travel 

$0.00 

$0.00 

$3,000.00 

Reference  Materials 

$0.00 

$0.00 

$400.00 

Totals 

$0.00 

$64,000.00 

$3,400.00 

Rank  = 

1 

3 

2 

Intangible  Factors 

PERS  4413 

PERS4413S 

PERS 

4413A 

PERS 

4413E 

PERS 

4413C 

Average 

Security 

8 

6 

8 

7 

7 

7.20 

Compatibility 

8 

9 

8 

9 

10 

8.80 

Reliability 

9 

9 

7 

8 

9 

8.40 

Scalability 

4 

4 

5 

7 

5 

5.00 

Affordability 

7 

6 

6 

6 

7 

6.40 

Ease  of  Use 

8 

10 

8 

9 

8 

8.60 

Wtd  pts  =  Average  *  Points 


Technical  Evaluation 

Do  Nothing 

Hire  Contractor 

NPS  Student 

Points 

Wtd  Pts 

Points 

Wtd  Pts 

Points 

Wtd  Pts 

Security 

2 

14.40 

9 

64.80 

7 

50.40 

Compatibility 

7 

61.60 

8 

70.40 

8 

70.40 

Reliability 

3 

25.20 

9 

75.60 

7 

58.80 

Scalability 

4 

20.00 

8 

40.00 

8 

40.00 

Affordability 

10 

64.00 

4 

25.60 

8 

51.20 

Ease  of  Use 

4 

34.40 

8 

68.80 

7 

60.20 

Total  Score 

219.60 

345.20 

331.00 

Table  1.  Cost  Analysis  For  Project 


Based  cn  a  cost  only  analysis,  the  best  option  is  to  do  nothing  and  keep  the 
current  system.  A  cost  analysis  should  not  be  done  solely  based  on  cost.  It  should  also 
include  intangible  factors  as  shown  above  (Cook  2001).  The  idea  is  to  interview  the 
primary  stakeholders  and  find  out  what  their  priorities  are  in  a  new  application  with 
respect  to  each  of  the  categories.  The  scores  for  these  factors  are  averaged  and  multiplied 
by  the  technical  evaluation  scores  for  each  category.  The  technical  evaluation  scores  are 
obtained  by  evaluating  each  option  with  respect  to  each  of  the  evaluation  criteria. 
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This  simple  comparison  of  estimated  costs  reveals  that  the  two  cheapest 
alternatives  are  to  do  nothing  and  fund  a  NPS  student  to  do  the  work,  however  the  best 
overall  evaluation  score  was  obtained  by  the  contractor.  The  NPS  student  option  was  a 
close  second  and  because  it  was  considerably  cheaper  to  do  fiscally  as  well  as  politically 
it  is  the  winning  choice  in  this  analysis. 
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HI.  REQUIREMENTS  ANALYSIS 


A.  DATA  REQUIREMENTS  (ERD) 

Based  upon  the  initial  discovery  trip,  subsequent  conversations  with  the  PERS 
4413  detail  shop,  use  of  existing  systems,  and  reports  a  data  model  was  developed  to 
capture  all  the  icq ui red  entities  for  the  system.  The  compilation  of  this  data  into 
structured  entities  with  relationships  and  business  rules  is  known  as  the  database  schema. 
The  database  schema  is  the  foundation  on  which  the  database  and  the  applications  are 
built.  (Kroenke  2000,  p  30)  After  sifting  through  the  available  information,  LT  Rader 
and  I  held  a  brainstorming  session  to  determine  a  potential  list  of  data  elements  that  may 
be  required.  The  result  of  this  session  is  depicted  below  in  Figure  5. 


Names 

Professional 

Information 


PCodes 


Phone 

Numbers 


Acquisition 

Information 


Addresses 


E-Mail 

Addresses 


Professional 
Public  Works  Qualifications 
Information 


Orders 


Command 

Information 


Awards 


Warfare 

Qualifications 


Billet 

Information 


Designators  Scabcc 
Information 

News 


Figure  5.  Brainstorming  Session  Results 
Based  on  these  results  and  further  discussion,  a  list  of  primary  entities  was 
determined  for  this  application  and  is  displayed  below  in  Table  2.  This  list  does  not 
include  any  lookup  tables  or  intersection  tables  which  will  be  discussed  later  on  in  this 
chapter. 

MEMBER  PREFERENCES 

BILLET  ACTIVITY 

QUALIFICATION 


Table  2.  Primary  Entities 
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Using  this  list  of  entities,  an  Entity  Relationship  Diagram  (ERD)  was  created  to 
outline  the  database  schema  and  is  shown  below  in  Figure  6. 
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Figure  6.  Entity  Relationship  Diagram 

The  key  elements  of  an  ERD  are  entities,  attributes,  identifiers,  and  relationships. 
Using  a  grammatical  analogy,  entities  can  be  defined  as  the  nouns,  or  something  that  can 
be  identified  in  the  users’  environment  that  they  want  to  track.  Attributes  are  the 
adjectives,  or  properties  of  the  nouns  that  describe  the  entity’s  characteristics. 
Relationships  are  the  verbs  that  describe  how  the  entities  interact  with  each  other.  While 
a  detailed  description  of  each  entity  and  their  attributes  can  be  found  located  in  the 
database  schema  located  in  Appendix  G,  the  ERD  above  provides  a  quick  and  easy  to 
read  view  of  the  database  schema.  When  a  relationship  between  entities  exists  that  is  a 
many  to  many  relationship,  a  special  table  must  be  created  to  capture  all  the  records  for 
those  entities.  This  table  is  called  an  intersection  table  and  it  contains  the  keys  of  the  two 
tables  in  the  relationship.  The  combination  of  those  keys  can  make  up  the  primary  key, 
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or  unique  identifier,  of  the  table.  An  alternate  method  of  uniquely  identifying  an 
intersection  table  is  to  create  a  separate  auto-numbered  field  that  becomes  the  primary 
key  for  the  table.  This  field  is  called  a  surrogate  key  and  has  advantages  in  that  when 
variables  need  to  be  passed  to  identify  which  record  needs  to  be  displayed  or  updated, 
you  only  have  to  pass  the  one  variable  vice  the  combination  of  keys  that  would  have 
made  up  the  primary  key. 

The  focal  point  for  this  ERD  is  the  MEMBER  table.  An  instance  of  the 
MEMBER  table  represents  one  CEC  service  member.  That  officer  is  described  by  the 
many  attributes  shown  above  in  the  ERD.  Each  member  can  have  from  zero  to  many 
duty  preferences.  Members  relay  their  personal  duty  preferences  and  priority  to  their 
respective  detailer  prior  to  negotiating  orders.  These  preferences  are  logged  by  the 
detailers  and  stored  in  the  PREFERENCES  entity.  Throughout  the  course  of  their  career, 
a  member  can  obtain  from  zero  to  many  qualifications.  Qualifications  include,  but  are 
not  limited  to  Professional  Engineer  Certification,  Registered  Architect,  and  Seabee 
Combat  Warfare.  All  of  the  possible  qualifications  are  stored  in  the  QUALIFICATION 
entity.  Qualifications  have  codes,  abbreviations,  descriptions,  and  importance  (sorting 
order  for  display).  A  single  qualification  can  be  obtained  by  zero  to  many  members. 
Because  the  MEMBER  to  QUALIFICATION  relationship  is  many  to  many,  an 
intersection  table  was  created  to  capture  all  the  records  of  each  service  member’s 
qualifications.  This  intersection  table,  MEMBER_QUALIFICATION,  contains  an 
additional  field  called  display  which  is  a  yes/no  field  designed  to  allow  the  user  to  select 
whether  or  not  that  particular  qualification  should  be  displayed  in  the  P-1  or  Staffing 
Plan.  For  example,  members  may  obtain  their  Engineer  in  Training  (EIT)  certification 
and  then  later  on  obtain  their  Professional  Engineers  (PE)  certification.  Once  a  member 
has  their  PE  certification,  there  is  no  need  to  display  the  EIT. 

Members  are  assigned  to  billets  represented  by  the  BILLET  entity.  Each  member 

is  usually  assigned  to  a  billet,  but  in  some  rare  cases  a  member  may  not  be  assigned  to  a 

billet.  A  billet  does  not  have  to  have  a  member  and  a  member  can  be  assigned  to  many 

billets  during  his  or  her  career.  The  relationship  between  MEMBER  and  BILLET  is  also 

a  many  to  many  relationship.  The  intersection  table  MEMBER_BILLET  was  created  to 

capture  all  instances  of  members  and  billets.  A  member  in  a  billet  will  have  a  report  date, 
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and  a  projected  rotation  date  (PRD).  Additionally,  there  is  a  field  in  this  table  called 
Type.  Upon  reviewing  my  notes  from  the  requirements  analysis  trip  and  also  the  existing 
data  that  is  to  be  imported,  I  came  across  some  additional  fields  that  are  tied  to  a  member 
(UltimateUIC  and  UltimateBSC).  These  fields  describe  an  ultimate  duty  station  to  which 
the  member  is  headed  and  are  different  than  the  UIC  and  BSC  information  on  the 
member.  Also  included  are  the  ultimate  estimated  reporting  date  (ULTEDA)  and 
ultimate  projected  rotation  date  (ULTPRD).  These  fields  will  be  populated  when  a 
member  has  received  orders  to  another  duty  station,  but  has  not  yet  left  the  current  duty 
station.  PERS  4413  is  interested  in  not  only  where  the  member  is,  but  where  their 
ultimate  destination  will  be.  The  existing  ERD  did  not  have  any  means  to  capture  this 
information.  Two  options  presented  themselves  to  resolve  this  issue.  The  first  option 
was  to  add  another  intersection  table  specifically  for  ultimate  destination  information  that 
would  essentially  contain  all  the  same  data  as  the  MEMBER_BILLET  table,  except  it 
would  hold  only  that  information  on  ultimate  destinations.  This  idea  was  quickly 
discarded  because  it  greatly  increased  the  complexity  level  of  the  data  model.  The 
second  idea  was  to  add  an  additional  field  into  the  MEMBER_BILLET  table  that  would 
be  a  required  field  and  toggle  between  Current,  Ultimate,  and  Previous.  A  billet  is  a 
billet  regardless  of  whether  it  is  a  current  station  or  ultimate  destination  for  a  member. 
One  member’s  ultimate  UIC  and  BSC  may  be  the  same  as  another  member’s  current  UIC 
and  BSC.  The  additional  field  accounts  for  the  case  where  a  member  has  a  current  billet 
and  an  ultimate  billet  without  adding  too  much  complexity  to  the  model  and  enables  the 
application  to  track  the  complete  duty  station  history  of  a  member. 

Billets  are  associated  with  an  activity  represented  by  the  ACTIVITY  entity.  An 
activity  can  have  many  billets,  but  a  billet  can  only  be  associated  with  one  activity.  An 
activity  is  not  required  to  have  a  billet,  but  a  billet  must  be  associated  with  an  activity. 

A  trained  eye  can  quickly  look  at  this  ERD  and  see  that  its  design  is  not 
completely  normalized.  Normalization  of  data  refers  to  the  way  data  attributes  are 
grouped  to  form  stable,  flexible,  and  adaptive  entities.  Normalization  is  the  procedure 
that  is  used  to  simplify  entities,  eliminate  redundancy,  and  build  flexibility  and 
adaptability  in  the  data  model.  (Whitten  1998,  pg.  337)  This  database  has  been  de- 
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normalized  intentionally.  Normalization  and  the  reasons  for  de- normalization  are 
discussed  in  detail  in  Chapter  IV. 

Finally,  there  are  several  lookup  tables  that  were  created  to  build  a  user-friendly 
interface  and  to  ensure  the  user  inputs  the  correct  values  for  designator,  P-Code,  and 
rank.  These  tables  are  not  related  to  any  of  the  tables,  but  are  called  upon  to  show  a  valid 
list  of  values  for  their  respective  fields  in  the  database  application. 

B.  APPLICATION  REQUIREMENTS  (DFD) 

The  application  must  support  complete  data  management  ranging  from 
maintaining  the  background  data  such  as  P-Codes,  designators,  and  qualifications  through 
the  management  of  a  member  as  the  officers  progress  through  the  course  of  their  careers. 
In  order  to  assign  members  to  billet  positions,  the  application  must  support  the  creation  of 
new  activities  and  billets  as  well  as  functionality  to  update  and  delete  them  as  well.  The 
Data  Flow  Diagram  (DFD)  describes  the  system  processes  that  support  this  functionality 
and  how  it  interacts  with  the  data  in  the  database. 
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C.  IDENTIFY  REPORTS 

As  discussed  in  previous  chapters,  there  are  two  main  reports  that  the  CEC 

detailers  use  in  the  daily  execution  of  their  duties.  These  two  reports  are  the  P- 1  and  the 

Staffing  Plan.  The  P- 1  is  used  primarily  to  provide  information  to  the  CEC  community 

whereas  the  Staffing  Plan  is  the  tool  that  is  used  to  help  the  detailers  with  the  assignment 
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of  members  and  the  overall  balance  of  the  Civil  Engineer  Corps.  The  P-1  provides 
information  on  where  all  the  CEC  officers  are  located  at  a  given  point  in  time  as  well  as 
their  billet  positions,  qualifications,  activity  phone  numbers,  addresses,  and  the  officer’s 
reporting  date.  Representative  samples  of  the  P-1  and  the  Staffing  Plan  are  discussed  and 
presented  in  Chapter  V.  The  Staffing  Plan  is  very  similar  to  the  P-1,  but  shows  the 
following  information  as  well: 

•  Officers  who  are  separating  (retiring  or  resigning) 

•  Pending  gains  (projected  new  officers  joining  the  CEC) 

•  Exception  personnel  and  billets  (billets  or  personnel  that  are  not  assigned 
and  are  pending  a  decision) 

•  Projected  rotation  dates  for  the  officers 

•  Ultimate  duty  station  information  (Activity  and  estimated  report  date) 

Additional  reports  that  are  not  required,  but  may  be  beneficial  include  the 
following: 

•  Member  reports  filtered  by  rank  and  projected  rotation  date 

•  Billet  reports  filtered  by  qualification  requirements 

•  Member  reports  filtered  by  qualifications  obtained 

•  Members  in  NMCB  activities  sorted  by  year  group  and  PRDs 

•  Report  on  member’s  duty  history 

•  Report  on  billet’s  history  (who  was  assigned  and  when) 

•  Billet  report  filtering  by  type  (Public  Works,  ROICC,  Seabee,  etc) 

These  additional  reports  will  make  it  easier  for  the  detailers  to  get  an  overall 
picture  of  where  there  constituents  are,  what  they  need  for  their  career,  and  what  billets 
the  CEC  needs  to  fill. 
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IV.  DESIGN 


A.  DESIGN  PHILOSOPHY 

Any  application  is  useless  if  the  end-users  do  not  find  it  easy  to  use  and  helpful  in 
the  execution  of  their  jobs.  If  the  application  is  more  of  a  burden  than  help,  resourceful 
users  will  find  another  way  to  work  and  leave  the  application  behind.  With  that  in  mind, 
the  tried  and  true  philosophy  of  keeping  it  simple  is  used.  The  database  design  and 
application  design  are  modeled  with  the  goal  of  providing  an  easy  to  use  interface  that 
quickly  produces  the  information  required  based  on  available  data.  A  poorly  designed 
database  can  make  designing  the  application  extremely  difficult,  if  not  impossible. 
Applications  with  flawed  designs  could  experience  performance  problems,  expandability 
issues,  and  data  integrity  problems.  (Blackburn,  et.  al  2000,  pg.  23)  A  comfortable 
balance  between  an  expert  technical  design,  user-friendly  interface,  and  reporting 
capabilities  is  obtained  by  de- normalizing  the  database  design  to  accommodate  for  ease 
of  use  while  not  sacrificing  performance  or  the  reliability  of  the  data. 

B.  DATABASE  DESIGN 

A  good  database  design  should  have  the  following  characteristics  (Whitten  1998, 
pp.  407-408): 

•  The  data  model  is  simple.  Data  attributes  that  describe  an  entity 
should  describe  only  that  entity. 

•  The  data  model  is  essentially  non-redundant.  Each  attribute,  other 
than  foreign  keys,  describes  at  most  one  entity. 

•  The  data  model  should  be  flexible  and  adaptable  to  future  needs. 
The  database  structure  should  be  capable  of  being  extended  or 
modified  without  significant  impact  to  current  programs. 

In  order  to  achieve  these  basic  goals  in  database  design,  a  specific  technique 
called  normalization  is  utilized. 

1.  Normalization 

A  fully  normalized  database  is  said  to  be  in  domain/key  normal  form  (DK/NF). 
This  is  the  highest  level  of  normalization  that  will  prevent  all  modification  anomalies.  To 
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understand  this  discussion,  a  proper  definition  of  terms  used  is  presented  below  in  Table 
3:  (Kroenke  2000,  pp  113-126) 


Term 

Definition 

Example 

Relation 

Two-dimensional  table.  Each  row 
holds  data  that  pertain  to  some  thing 
or  a  portion  of  some  thing.  Each 
column  (field)  contains  data 
regarding  an  attribute. 

Table:  MEMBER;  Each  row  represents  a  service 
member  and  each  column  is  a  different  field 
describing  the  member  (Name,  SSN,  Sex,  etc) 

Functional 

dependency 

A  relationship  between  or  among 
attributes.  Given  the  value  of  one 
attribute,  the  value  of  another 
attribute  can  be  looked  up. 

Given  a  particular  activity  (Activity ID  in  table 
ACTIVITY),  you  can  look  up  what  billet(s)  are  in 
that  activity.  Billet  is  functionally  dependent  on 
Activity. 

Candidate 

key 

A  group  of  two  or  more  attributes 
that  uniquely  identifies  a  row. 

In  the  table  MEMBER,  MemberlD  and  SSN  are 
both  keys  because  they  uniquely  identify  a 
particular  member. 

Primary  key 

The  candidate  key  chosen  to  be  the 
main  key,  which  identifies  the  row. 

MemberlD  is  the  primary  key  in  the  MEMBER 
table 

Modification 

anomalies 

Changing  data  in  one  table  causes  an 
undesirable  change  in  another 
attribute. 

In  the  table  MEMBER,  the  attribute  Designator 
describes  what  designator  each  member  has.  If  the 
designator  does  not  come  from  a  predefined  list 
(table),  a  deletion  of  one  member  could  result  in 
the  deletion  of  that  particular  designator  if  the 
member  was  the  only  one  to  hold  that  designator. 

Constraint 

Any  rule  governing  the  static  values 
of  an  attribute.  Includes  edit  rules, 
intrarelation  and  interrelation 
constraints,  functional  dependencies, 
and  multi-value  dependencies. 

SSN  in  table  MEMBER  can  only  have  9 
characters. 

A  member  can  have  many  qualifications  and  a 
qualification  can  be  obtained  by  many  members. 

Domain 

A  description  of  an  attribute’s 
allowed  values  (both  physical  and 
logical). 

In  the  table  MEMBER,  the  domain  for  the 
attribute  Sex  is  (M,  F).  Logical  domain  is 
member’s  gender. 

Transitive 

dependency 

A  table’s  key  determines  one 
attribute  and  that  attribute  in  turn 
determines  another  attribute. 

Consider  Member,  Rank,  and  Pay  grade.  The 
member  determines  the  rank  and  the  rank 
determines  the  paygrade,  thus  the  member 
indirectly  determines  paygrade.  (If  a=b  and  b=c, 
then  a=c) 

Multi-value 

dependency 

A  condition  in  a  relation  with  three 
or  more  attributes  in  which 
independent  attributes  appear  to  have 
relationship  they  do  not  have. 

Consider  a  member  with  (MemberlD,  PCode,  and 
Qualification).  A  member  can  have  multiple 
values  of  PCode  and  Qualification.  PCode  and 
Qualification  have  no  relationship,  but  appear  to  in 
the  relation. 

Table  3.  Database  Design  Definitions 

While  DK/NF  is  the  highest  form  of  normalization,  many  database  designs  do  not 
meet  this  criteria  and  are  thus  in  other  forms  ranging  from  First  Normal  Form  (INF)  to 
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Fifth  Normal  Form  (5NF).  Each  of  these  forms  is  summarized  below  (Kroenke  2000,  pp. 
120-126): 

•  First  Normal  Form  (INF)  -  Any  table  of  data  that  meets  the  definition  of  a 
relation. 

•  Second  Normal  Form  (2NF)  -  All  non-key  attributes  are  dependent  on  all 
of  the  keys.  An  example  of  this  would  be  if  the  MEMBER  table  contained 
the  field  BilletTitle.  BilletTitle  is  a  non-key  attribute  that  is  not  dependent 
on  MemberlD.  To  get  this  table  into  2NF,  a  separate  table,  BILLET, 
needs  to  be  created  and  the  field  BilletTitle  needs  to  be  moved  to  this 
table. 

•  Third  Normal  Form  (3NF)  -  There  are  no  transitive  dependencies. 

•  Boyce-Codd  Normal  Form  (BCNF)  -  Every  determinant  is  a  candidate 
key. 

•  Fourth  Normal  Form  (4NF)  -  It  is  in  BCNF  and  there  are  no  multi-valued 
dependencies. 

•  Fifth  Normal  Form  (5NF)  -  Relations  that  can  be  divided  into  sub- 
relations,  but  then  cannot  be  reconstructed.  This  is  an  obscure  concept 
that  has  no  clear  meaning  and  is  included  here  for  completeness  only. 

•  Domain/Key  Normal  Form  (DK/NF)  -  All  constraints  on  relations  are 
logical  consequences  of  domains  and  keys. 

The  Entity  Relationship  Diagram  was  introduced  in  Chapter  III.  (Figure  6)  This 
diagram  was  the  result  of  several  iterations  during  the  design  process.  The  initial  design 
was  closer  to  DK/NF  than  the  final  version.  For  optimization  reasons  including  ease  of 
use  and  ease  of  reporting,  the  original  design  was  de- normalized  to  get  to  the  database 
design  its  final  state.  The  original  ERD  is  shown  below  in  Figure  8. 
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Figure  8.  Original  Entity  Relationship  Diagram 

As  shown  above,  the  original  ERD  was  much  more  complex  than  the  final 
version.  Several  tables  were  removed  in  favor  of  de-normalization.  While  normalization 
avoids  modification  anomalies,  sometimes  its  value  is  not  worth  the  price  and  ease  of  use. 
The  following  discussion  details  the  reasons  for  de- normalizing  each  table. 

•  EM  ATE  -  In  reality,  a  member  can  have  any  number  of  email  addresses, 
but  do  we  really  want  to  track  all  of  them?  This  was  discussed  with  the 
detailers  and  they  were  only  concerned  with  the  primary  and  possibly  a 
secondary  address.  With  that  in  mind,  the  joins  in  the  model  were 
simplified  by  adding  three  email  address  fields  to  the  table  MEMBER 
(Work,  Home,  and  Alternate). 

•  PHONE  -  It  is  reasonable  to  assume  that  a  member  will  only  have  a  finite 
quantity  of  phone  numbers.  Based  on  this  assumption,  the  PHONE  table 
was  deleted  and  fields  were  added  to  the  MEMBER  table  for  phone 
numbers  (Home,  Work- DSN,  Work- Commercial,  Cell,  and  Pager) 

•  ACTIVITYPHONE  -  The  same  argument  made  above  for  the  member’s 
phone  numbers  can  be  made  for  the  activity’s  phone  numbers.  Phone 
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number  fields  were  added  to  ACTIVITY  and  the  table 
ACTIVITYPHONE  was  dropped. 

•  PCODE  -  A  member  can  possibly  obtain  more  than  one  subspecialty  code 
(PCode),  but  the  data  in  the  current  production  systems  only  support  one 
for  each  member.  Since  the  CEC  detail  shop  did  not  have  an  interest  in 
tracking  anything  other  than  the  main  sub  specialty  code  for  the  member, 
the  P-Code  field  was  added  to  the  MEMBER  table  and  the  relationship 
was  dropped  in  favor  of  a  lookup  table. 

•  BILLET_QUALIFICATION  -  A  billet  has  a  maximum  of  two 
qualifications  (primary  and  secondary).  Because  of  this  finite  number,  the 
many-to-many  relationship  between  BILLET  and  QUALIFICATION 
seemed  unnecessary.  To  keep  with  the  design  philosophy  of 
simplification,  the  intersection  table  was  dropped  and  two  fields  were 
added  to  BILLET  (PrimaryAQD  and  SecondaryAQD).  These  fields  are 
still  validated  in  the  database  by  looking  up  their  values  from 
QUALIFICATION  and  not  allowing  any  entries  not  in  the  table  that  do 
not  exist  in  the  table  QUALIFICATION. 

The  process  of  de- normalization  produces  an  effect  that  is  worth  noting.  While 
the  database  is  easier  to  use  and  the  relationships  are  less  complicated,  there  is  a  potential 
for  data  anomalies  in  the  future.  For  example,  if  information  for  P-Codes  were  to  change 
in  the  Navy  as  they  recently  have,  a  large  data  update  would  be  required  for  both  the 
MEMBER  and  BILLET  tables.  An  example  of  this  would  be  the  recent  change  in  the 
Information  Technology  P-Code  from  0089  to  6201.  Because  the  data  in  the  MEMBER 
and  BILLET  tables  are  not  related  to  the  PCODE  table  via  a  foreign  key,  each  member 
and  each  billet  that  has  a  P-Code  of  0089  would  have  to  be  changed  to  6201.  This  can  be 
done  through  automated  routines,  but  requires  specialized  skill  and  can  be  dangerous  to 
execute.  If  the  data  model  were  normalized,  the  only  change  in  the  database  would  be  to 
change  0089  to  6201  in  the  PCODE  table  and  the  update  would  be  done  for  the  entire 
database.  The  exact  same  case  can  also  be  made  for  the  designator  field  in  MEMBER 
and  BILLET. 

2.  Data  Model  Verification 

Data  model  verification  is  a  process  in  which  the  ER  model  is  verified  against  end 
user  views  and  required  transactions,  security,  and  business-imposed  data  requirements 
and  constraints.  During  this  process  each  entity,  its  attributes,  allowable  values,  and  any 
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business  rules,  which  apply  to  any  processing  transactions,  are  evaluated  for  the 
following  reasons  (Dr  Xinping  SHI): 

•  Attributes  may  lead  to  a  revision  of  the  entities  themselves. 

•  Attributes  provide  clues  about  the  relationships  as  they  are  defined  by  the 
primary  and  foreign  keys. 

An  example  of  this  analysis  is  the  PCode  field  in  MEMBER  and  BILLET.  A 
subspecialty  code  is  a  combination  of  a  four-digit  number  and  one  character  letter.  The 
number  defines  the  area  of  expertise  and  the  letter  defines  the  level  of  education  and 
experience.  Originally,  I  had  designed  this  to  be  one  field  that  was  a  variable  character 
field  with  a  length  of  five.  After  evaluating  how  the  end  user  would  be  interfacing  with 
the  system,  I  found  that  this  method  was  a  bit  cumbersome.  For  each  subspecialty  code, 
nine  possible  character  codes  define  the  level  of  education  and  experience.  Since  there 
are  108  different  codes  for  the  subspecialty  rating,  the  number  of  records  in  the  PCode 
table  would  have  multiplied  by  nine  yielding  972  records  to  sort  through  when  searching 
for  the  correct  value.  The  solution  was  to  split  the  field  into  two  parts,  the  first  being  the 
subspecialty  code  itself,  and  the  second  being  the  one  character  suffix  that  describes  the 
level  of  education  and  experience.  This  makes  looking  up  the  values  of  the  PCode  much 
easier  for  the  user  and  still  maintains  the  data  integrity  by  not  allowing  any  values  other 
than  those  in  the  list. 

Another  issue  that  was  discovered  during  this  process  was  how  to  deal  with  the 
name  of  a  member.  The  member  name  data  that  is  imported  comes  in  one  field  with  the 
last  name,  first  name,  middle  name  (or  initial),  and  suffix  (Jr.,  Sr.,  etc)  separated  by  a 
space.  Because  each  member’s  name  can  vary,  it  was  impossible  to  split  each  part  into 
separate  fields.  The  last  name  and  first  name  split  easily,  but  when  it  came  to  split  the 
middle  name  and  suffix  into  their  respective  fields  a  problem  surfaced.  Some  members 
have  two  middle  names.  For  example,  if  I  were  to  take  the  name  field  and  split  it  four 
times  into  LastName,  FirstName,  MiddleName,  and  Suffix  it  would  work  most  of  the 
time  for  standard  names.  If  a  member  had  a  name  like  Weinstein  Brian  Louis  Wiley  Jr., 
then  the  middle  name  would  become  Louis  and  the  suffix  would  become  Wiley  and  Jr. 
would  have  no  place  to  go.  The  solution  was  to  separate  the  first  and  last  names  of  the 
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members  and  keep  the  middle  names  and  suffixes  together  in  one  field 
MiddleNameSuffix. 

3.  Logical  Design 

The  logical  design  of  the  database  was  accomplished  using  the  CASE  (Computer- 
Aided  Systems  Engineering)  tool  Visible  Analyst.  The  entities,  relationships,  attributes, 
data  types,  domains  (allowable  values),  and  default  values  were  created  in  Visible 
Analyst.  Visible  Analyst  maintains  a  repository,  where  all  specifications  associated  with 
the  database  design  are  kept.  The  repository  functions  interactively  with  the 
diagramming  and  rules  to  create  an  organized  database  of  project  information  for  the 
project  automatically  as  it  is  developed.  The  project  repository  is  automatically  updated 
and  maintained  during  all  work  sessions,  and  it  can  be  accessed  at  any  time  to  manually 
add,  delete,  edit,  or  review  entries.  From  the  repository,  Visible  Analyst  allows  the 
designer  to  generate  the  database  schema  and  export  it  to  the  Access  database.  The 
Access  database  is  created  with  all  the  tables,  fields,  relationships,  default  values,  and 
referential  integrity  settings  from  Visible  Analyst.  This  can  be  an  invaluable  tool  while 
working  on  the  design  of  the  database  to  quickly  change  the  design  and  export  it  to 
Access  for  validation  and  verification.  Visible  Analyst  also  includes  analysis  tools  to 
identify  syntax  errors  (unnamed  entities  and  relationships)  as  well  as  potential 
normalization  errors.  During  the  normalization  analysis,  Visible  Analyst  checks  for  and 
warns  of  many-to-many  relationships,  optional- to-optional  relationships,  and  mandatory 
one-to-one  relationships  in  both  directions. 

As  mentioned  previously,  the  ERD  for  this  project  changed  several  times  during 
the  database  design  process.  I  made  all  the  changes  in  Visible  Analyst  to  ensure 
consistency  and  then  export  the  database  schema  directly  into  Microsoft  Access.  Visible 
Analyst  would  drop  the  existing  tables,  add  the  new  tables,  and  recreate  the  relationships 
in  the  database.  The  only  downside  to  working  in  this  manner  is  that  any  data  in  an 
existing  table  that  is  dropped  by  Visible  Analyst  and  replaced  with  a  new  table  is  lost. 
There  are  two  ways  I  used  to  work  around  this  inconvenience.  The  first  is  to  keep  a  copy 
of  the  database  prior  to  updating  it  and  then  import  the  data  that  is  dropped  from  the  new 
one.  The  second  method  is  to  export  only  those  tables,  which  have  changed  in  Visible 

Analyst.  For  example,  if  I  made  modifications  to  the  MEMBER  and  BILLET  table  but 
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left  the  ACTIVITY  table  alone,  I  would  exclude  the  ACTIVITY  table  in  Visible  Analyst 
from  the  export  procedure.  The  MEMBER  and  BILLET  tables  would  then  be  updated 
and  the  ACTIVITY  table  would  remain  intact  with  all  of  its  data. 

The  result  of  the  logical  design  can  be  partially  seen  in  the  ERD,  but  to  gain  the 
full  picture  of  each  entity  and  its  attributes,  the  data  dictionary  is  needed.  The  data 
dictionary  breaks  down  each  entity  and  shows  each  attribute’s  data  type,  length,  allowed 
values,  and  whether  it  is  a  required  field.  This  data  dictionary  can  be  found  in  Appendix 
G. 

4.  Physical  Design 

While  logical  design  is  primarily  concerned  with  normalization,  the  physical 
design  relates  mostly  to  performance.  Optimizing  the  physical  performance  of  the 
Database  Management  System  (DBMS)  can  be  a  challenging  task  for  large-scale 
production  systems.  Since  this  project  is  a  prototype  using  Microsoft  Access,  the  concern 
for  the  physical  design  of  the  system  is  not  as  great  as  it  would  be  for  a  large-scale 
enterprise  system.  In  reality,  there  may  be  only  one  user  of  the  system  and  the 
application  will  most  likely  be  run  off  his  hard  drive.  If  the  other  detailers  desire  to  use 
the  system,  then  a  slightly  different  physical  implementation  will  be  necessary.  In  this 
case  the  database  would  be  split  into  two  parts,  the  first  part  being  the  actual  data  tables, 
queries,  reports,  macros,  and  modules  and  the  second  part  being  the  user  interface  forms. 
The  first  portion  would  be  installed  on  a  shared  network  drive  only  accessible  by  the 
CEC  detailers  and  each  detailer  would  have  a  client  installed  on  their  local  machine  that 
would  have  their  own  personal  copy  of  the  front  end  and  link  to  the  centralized  database. 
This  would  allow  all  to  share  the  same  data  while  minimizing  any  maintenance  upgrades 
to  the  application  logic  keeping  all  the  queries,  macros,  and  modules  in  one  central 
location.  This  scalability  issue  is  discussed  more  in  Chapter  VI. 

C.  APPLICATION  DESIGN 

In  the  original  concept  of  the  project,  consideration  was  given  to  a  web-based 
design  as  well  as  a  client-server  design.  During  the  requirements  analysis  trip,  it  became 
clear  that  there  was  no  support  for  a  web-based  detailing  management  system  for  the 
CEC  detailers.  The  IT  staff  would  not  support  any  new  applications  that  would  require 
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their  support  (hardware  or  software)  without  a  sufficient  review.  Time  constraints  for  the 
project  dictated  another  solution.  A  small  Access  database  application  run  by  a  few  users 
to  help  them  in  their  job  would  not  be  a  concern  for  the  IT  staff.  The  final  decision  was 
to  design  the  application  for  the  one  user  who  was  likely  to  use  it,  with  the  option  of 
splitting  it  up  into  a  client-server  type  model.  The  product  chosen  for  the  prototype 
application  was  Microsoft  Access  due  to  its  versatility,  cost,  and  the  fact  that  it  is  a  very 
robust  database  system  for  smaller  applications  like  this  one. 

1.  Hardware  &  Software 

The  database  application  is  designed  to  run  on  PC-compatible  machines  meeting  a 
minimum  of  the  following  requirements: 

•  Processor  speed  should  be  at  least  Pentium  III,  700  MHz  or  greater 

•  Hard  drive  space  should  have  at  least  1  GB  free 

•  Computer  should  have  a  minimum  of  128  MB  of  memory 

To  run  the  application,  the  user  will  require  Microsoft  Access  2000  running  on  a 
Windows  platform.  The  preferred  operating  system  is  Windows  XP  Professional,  as  it  is 
the  most  stable  of  all  the  Microsoft  Windows  platforms  and  is  the  industry  standard  for 
office  computers.  The  database  application  will  run  onWindows  2000  and  should  run  on 
earlier  versions  of  Windows  (9X  and  NT)  but  has  not  been  tested  on  these  operating 
systems. 

2.  Migration  from  Legacy  Systems 

In  an  ideal  situation,  the  new  application  would  take  over  the  functionality  of  the 
legacy  system,  and  the  legacy  system  would  be  dropped  when  the  migration  was 
complete.  In  this  particular  case,  the  application  is  not  a  replacement  for  the  current 
production  systems  but  rather  a  prototype  for  what  could  be  used  as  a  detailing 
management  system.  The  benefit  of  this  prototype  is  that  it  has  functionality  that  can  be 
used  in  concert  with  the  legacy  systems  to  help  the  CEC  detailers  execute  their  duties.  A 
true  migration  from  the  current  legacy  systems  requires  work  and  analysis  far  beyond  the 
scope  of  this  thesis.  This  issue  is  addressed  in  Chapter  VII. 
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3.  Security 

The  security  of  the  application  is  important  for  two  reasons:  1)  to  protect  the  code 
and  2)  to  protect  the  data.  Microsoft  Access  has  a  built  in  security  system  that  allows  you 
to  add  simple  security  such  as  adding  a  database  password,  but  it  also  allows  very 
complex  security  schemes  including  encryption  and  security  groups.  Since  this  project 
contains  sensitive  Privacy  Act  data  and  has  complex  forms  and  queries,  I  chose  to  secure 
it  using  user- level  security  instead  of  a  simple  database  password. 

a.  Database  Password 

To  protect  against  unauthorized  personnel  accessing  the  database,  a  simple 
database  password  can  be  set.  This  protects  the  database  with  the  password  set  but  still 
allows  users  to  use  Access  and  other  databases  on  the  machine  or  network.  Microsoft 
Access  encrypts  the  password  so  that  the  database  password  is  secured  and  cannot  be 
accessed  by  reading  the  database  file  directly.  (Blackburn  2000,  pg.  549)  This  password 
only  restricts  opening  the  database.  Once  the  database  is  open,  the  user  has  full  access  to 
all  its  objects  unless  further  security  is  set. 

b.  User-Level  Security 

By  default,  all  users  have  rights  to  all  objects  in  the  database.  Microsoft 
Access  allows  the  administrator  to  add  user  level  security  by  assigning  permissions  for 
database  objects  (forms,  modules,  reports,  etc)  to  either  specific  users  or  groups  of  users. 
Access  comes  with  two  default  groups — Users  and  Admin.  The  Admin  group  has  rights 
to  administer  the  database,  can  perform  any  action  on  any  database  object,  and  can  create 
users  and  groups.  By  default,  all  users  have  rights  to  all  objects  in  the  database. 
Fortunately,  Access  comes  with  a  User-Level  Security  Wizard  that  allows  the 
administrator  to  set  up  security  users  and  groups  in  a  quick,  easy  to  use  interface.  For 
this  project,  I  chose  to  create  one  additional  group — Full  Data  Users.  I  set  the 
permissions  for  this  group  to  allow  them  full  permissions  to  edit  data  but  not  alter  the 
design  of  any  database  objects.  Following  good  security  practices,  I  also  disabled  any 
permissions  for  the  default  user  group  as  well  as  user-level  permissions  for  Admin  and 
User.  I  created  accounts  for  each  of  the  detailers  and  placed  them  in  the  Full  Data  User 
group  assigning  them  user  names  and  passwords.  I  also  created  an  account  for  myself  as 
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the  administrator  of  the  database.  Currently  I  am  the  only  one  with  full  rights  to  the 
database  objects,  but  after  proper  training  PERS4413S  (Community  Management 
Analyst)  will  be  given  escalated  rights  so  he  can  properly  manage  the  database. 

Although  the  Access  database  password  and  user- level  passwords  is 
supposedly  encrypted  and  cannot  be  hacked  into,  there  are  several  programs  available 
that  recover  lost  passwords  for  Microsoft  Access  databases  and  other  Microsoft  Office 
products.  In  theory,  a  malicious  user  could  use  one  of  these  programs  to  gain  the 
database  password  and  gain  access  to  the  system.  This  security  scheme  does  protect  the 
database  application  and  data  fom  the  average  user  and  is  sufficient  for  the  prototype 
application. 

D.  DESIGN  SUMMARY 

Although  the  database  design  is  not  an  optimal  model,  extensive  effort  was 
undertaken  to  ensure  that  the  model  would  support  the  users’  requirements  as  well  as 
maintain  data  integrity.  The  original  model  was  de- normalized  in  several  areas  to 
accomplish  this  objective.  Data  integrity  for  these  areas  was  strengthened  by  providing 
allowable  values  for  entry  with  lookup  tables.  The  resulting  data  model  supports  the 
users  need  for  a  comfortable  interface  while  minimizing  the  amount  of  de- normalization. 
Due  to  the  nature  of  the  data  contained  in  the  application,  a  user- level  security  system 
was  put  in  place  to  protect  the  data  from  being  viewed  by  unauthorized  personnel  and  to 
protect  the  application  from  accidental  tampering. 
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V.  DEVELOPMENT  &  IMPLEMENTATION 


A.  DATA  IMPLEMENTATION 

Data  implementation  involves  the  physical  construction  of  the  database  based  off 
the  logical  design.  The  generation  of  the  database  from  the  CASE  tool  Visible  Analyst 
was  discussed  in  Chapter  IV.  Implementation  of  the  data  requires  decisions  on 
appropriate  field  type  values  and  lengths,  default  values,  input  masks  (to  force  correct 
data  entry),  and  visual  formatting  (for  example,  making  a  date  display  in  a  particular 
manner).  An  example  of  this  are  the  phone  fields  located  in  the  MEMBER  table  and  the 
ACTIVITY  table.  If  the  application  is  only  going  to  deal  with  phone  numbers  in  the 
United  States,  then  it  would  make  sense  to  allow  just  a  ten  digit  number  field  that  is 
formatted  for  standard  phone  numbers  that  users  are  accustomed  to.  In  this  case,  many 
phone  numbers  are  international  with  varying  digits  and  sometimes  character  codes.  The 
decision  to  leave  the  phone  fields  as  a  variable  character  field  capable  of  holding  30 
characters  was  made  based  on  the  variety  of  phone  numbers  in  the  data. 

A  final  important  area  involved  with  the  data  implementation  is  the  creation  of 
indexes.  Indexes  improve  the  performance  of  any  queries  that  are  performed  against  a 
field  and  are  best  kept  for  fields  against  which  the  user  will  be  doing  many  queries, 
sorting,  or  grouping.  Indexes  should  only  be  used  where  deemed  necessary  because 
whenever  a  new  row  is  inserted  into  a  table,  a  new  entry  is  made  into  every  index  in  that 
table.  Indexes  add  to  the  size  of  the  database  file,  reduce  concurrency  (the  ability  of  more 
than  one  user  to  modify  a  page  at  the  same  time)  in  multi-  user  applications,  and  decrease 
performance  when  you  update  data  in  fields  that  are  indexed  or  when  you  add  or  delete 
records. 

Microsoft  Access  has  a  feature  which  produces  a  report  on  selected  tables  and 
other  objects  in  the  database.  This  report  is  a  comprehensive  list  of  each  table,  its 
attributes,  and  detailed  information  on  each  field.  This  is  often  referred  to  as  the  database 
schema  or  sometimes  a  data  dictionary.  The  complete  database  schema  for  this  project 
can  be  found  in  Appendix  G. 
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B.  APPLICATION  STRUCTURE  DESIGN 


Traditional  Access  applications  have  been  a  single  machine  application  with  only 
one  user.  As  times  changed  and  networks  became  more  prevalent,  the  need  for  shared 
applications  arose  and  Microsoft  provided  further  advanced  versions  of  Access.  The 
requirement  for  users  to  share  data  spurred  the  development  of  client/server  applications. 
Today,  there  are  several  different  methods  to  structure  your  database  application.  The 
three  methods  I  will  discuss  are  single-tier  applications,  two-tier  applications,  and  three- 
tier  applications.  The  following  terms  are  commonly  used  when  referring  to  application 
structures  and  their  implementation: 

•  Presentation  layer  -  Contains  the  graphical  and  visual  elements  of  the 
application  and  is  often  referred  to  as  the  Graphical  User  Interface  (GUI). 

•  Application  logic  layer  -  Contains  the  business  rules  associated  with  an 
application. 

•  Data  layer  -  Contains  the  application  data,  usually  in  a  database. 

•  Client  -  The  local  computer  used  by  the  end  user. 

•  Server  -  Centralized  server  that  has  shared  access  across  many  users. 

1.  Single-Tier  Applications 

A  single -tier  application  is  one  where  all  the  layers  described  above  reside  as  one 
unit  on  one  machine.  This  type  of  application  is  relatively  easy  to  build  and  implement 
initially.  The  downside  to  this  application  structure  is  that  there  is  no  sharing  of  data 
across  users.  It  is  an  excellent  structure  for  a  small  application  designed  for  just  one  user. 

2.  Two  -Tier  Applications 

A  two-tier  application  is  an  application  where  the  presentation  layer  resides  on  the 
client  and  the  data  is  located  on  the  server.  The  application  logic  may  reside  on  either  the 
client  or  the  server.  When  it  resides  on  the  client,  the  application  structure  is  typically 
called  a  “fat”  (sometimes  called  thick  or  rich)  client.  Conversely,  when  the  application 
logic  resides  on  the  server  with  the  data,  it  is  called  a  “thin”  client.  The  separation  into 
two  tiers  allows  the  sharing  of  data,  consistency  of  usage,  and  simplified  report 
generation.  Two-tier  fat  client  implementations  can  be  difficult  to  maintain  because 
whenever  there  is  any  change  in  the  application  logic,  the  change  must  be  applied  to  each 
client  using  the  system.  Fat  client  implementations  also  require  the  clients’  machines  to 
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be  sufficiently  powerful  to  run  both  the  application  layer  and  the  presentation  layer.  Thin 
client  applications  are  easier  to  maintain,  as  all  the  application  logic  is  located  in  one 
place.  The  trade-off  with  this  type  of  implementation  is  that  it  puts  a  larger  strain  on  the 
server  to  support  multiple  requests  to  the  application  logic  layer. 

3.  Three-tier  Applications 

As  the  name  implies,  three-tier  applications  are  broken  into  three  separate  parts. 
The  presentation  layer  resides  on  the  client,  the  application  layer  is  located  on  a  business 
(or  application)  server,  and  the  data  layer  resides  on  a  database  server.  This  model  can 
produce  the  most  efficient  and  flexible  applications.  However,  three-tier  applications  are 
also  the  most  complex  to  build.  Microsoft  Access  cannot  implement  a  three-tier 
application  fully  by  itself,  but  can  play  a  role  in  the  whole  system  by  being  part  of  the 
presentation  or  data  layer.  (Blackburn  2000,  pg.  19) 

4.  Structure  Selection 

For  this  thesis,  I  chose  to  use  a  thin  two-tier  application  structure.  For  the  size  of 
the  application  and  its  expected  use,  this  structure  offers  the  greatest  efficiency  and 
flexibility  while  also  simplifying  the  maintenance  of  the  application.  Any  further 
changes  to  the  application  logic  can  be  accomplished  in  one  place,  on  the  server,  instead 
of  making  changes  to  each  client’s  computer.  At  the  time  of  this  writing,  each  user  at  the 
detail  shop  is  still  working  on  outdated,  less  powerful  machines.  Shifting  the  processing 
load  to  the  more  powerful  server  will  increase  the  performance  of  the  application. 

C.  GRAPHICAL  USER  INTERFACE  DESIGN  (GUI)  -  USER  MANUAL 

For  the  user,  a  graphical  user  interface  (GUI)  is  the  application  The  GUI  is  how 
the  end-users  accomplish  their  tasks,  and  great  care  must  go  into  designing  comfortable, 
easy  to  use  forms  for  the  add,  update,  and  delete  requirements  of  the  application.  All 
forms  were  designed  for  a  user  screen  resolution  of  1024  x  768.  Extensive  effort  was  put 
into  the  design  of  each  form  to  display  the  information  in  a  logical  manner  and  minimize 
the  number  of  mouse  clicks  required  for  the  user.  At  the  same  time,  too  much 
information  on  one  form  can  create  confusion  for  the  user,  so  a  careful  balance  must  be 
maintained.  In  designing  the  interface,  I  attempted  to  adhere  to  three  main  principals: 

•  A  form  should  serve  as  the  main  interface  to  the  information  in  the 
database  including  all  data  operations  like  adding  or  deleting  records. 
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A  form  should  link  all  of  the  database  information  components  together. 
For  example,  preferences  and  members  only  share  a  numerical 
relationship  as  far  as  Access  is  concerned,  but  on  the  member  form  the 
end-user  can  add,  edit,  update,  and  delete  all  the  preference  information 
for  that  member. 

The  forms  should  provide  for  an  intuitive  navigation  through  the  program 
The  switchboard,  which  controls  all  of  the  interfaces  to  the  application, 
can  be  used  as  well  as  a  menu  system  on  each  form. 


For  this  database  application,  I  chose  to  use  a  standard  Access  switchboard  to 
control  how  the  user  interacted  with  the  database.  The  switchboard  presents  a  logical 
flow  of  sequences  for  the  user,  organized  by  type  of  action.  A  screen  shot  of  the  main 
switchboard  is  shown  below. 


Figure  9.  Main  Switchboard 


The  main  switchboard  leads  the  user  to  four  different  areas — data  import/cleanup, 
CEC  member  management,  background  data  management,  and  report  viewing.  Each  of 
these  switchboards  controls  the  user’s  access  to  specific  areas  of  the  application. 

1.  Data  Import  and  Cleanup 

If  the  user  has  not  already  imported  the  data,  there  is  a  four- step  process  that  is 
outlined  in  the  Data  Import  and  Cleanup  Switchboard  shown  below  in  Figure  10. 
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Figure  10.  Data  Import  &  Cleanup  Switchboard 

The  first  step  is  to  import  the  billets  from  the  delimited  text  file.  This  process  is 
execute  by  a  single  macro  which  brings  in  the  data,  cleans  it  up  according  to  predefined 
rules,  and  then  presents  the  billet  review  form  shown  below  in  Figure  11.  This  review 
form  presents  the  user  with  a  list  of  imported  billets  that  could  not  be  associated  with  an 
existing  activity.  The  user  is  presented  with  the  option  to  modify  the  billet,  delete  the 
billet,  create  a  new  activity  for  the  billet,  or  add  the  billet  to  the  exception  activity  list, 
which  will  allow  the  user  to  keep  the  billet  and  make  a  decision  on  it  later.  If  the  user 
wants  to  add  this  billet  to  an  existing  activity,  the  UIC  field  is  a  dropdown  list  that  shows 
all  available  activities  and  will  not  accept  any  entries  that  are  not  already  in  the  list. 
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Figure  11.  Billet  Review  Form 


If  the  user  selects  to  delete  the  billet,  a  warning  message  is  displayed  as  shown 
below  in  Figure  12.  This  helps  prevent  the  user  from  accidentally  deleting  a  record. 
Throughout  the  entire  application,  a  warning  message  similar  to  this  is  displayed 
whenever  a  record  is  selected  to  be  deleted. 


Figure  12.  Delete  Warning  Message 

After  completing  the  billet  import  and  review  process,  the  user  will  import  the 
delimited  bodies  file  and  be  presented  with  a  more  complex  member  review  form  shown 
below  in  Figure  13.  Only  the  tabs  and  column  headings  are  shown  in  order  to  protect  the 
CEC  members’  personal  information.  See  Appendix  #  for  a  view  of  all  the  forms.  This 
form  presents  the  user  seven  different  views  of  the  imported  personnel  data.  These  views 
are  filtered  according  to  the  rules  established  by  the  Community  Management  Analyst 
and  are  designed  to  help  him  sort  through  the  over  1400  members  that  are  imported 
quickly  and  efficiently.  A  summary  of  the  rules  is  presented  below: 
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•  ACC  -  Checks  members  where  ACC  is  not  equal  to  100.  Regular  CEC 
members  have  an  ACC  equal  to  100. 

•  USNR  -  Checks  members  who  have  a  designator  of  5105  (USNR)  and  a 
rank  of  LCDR  or  above.  Sometimes  a  few  reserve  officers  are  imported 
and  need  to  be  deleted.  The  Community  Management  Analyst  is  the  only 
one  who  knows  which  personnel  belong. 

•  Ultimate  EDA  -  Checks  a  member’s  ultimate  report  date  and  shows  only 
those  members  whose  report  date  is  prior  to  the  current  date. 

•  Pending  Gains  -  Checks  members  where  Activity  =  “PNDING  NAVY 
GAIN.”  These  could  be  members  in  Officer  Candidate  School  or  another 
program.  PERS  4413S  will  make  the  decision  on  what  to  do  with  these 
members  (include  them,  delete  them,  or  reassign  them). 

•  No  Orders  Loss  -  Checks  members  where  ultimate  activity  =  “NO 
ORDERS  LOSS.”  Sometimes  the  production  systems  lose  particular  data 
for  a  member  regarding  their  current  orders,  etc.  These  records  are 
manually  corrected  by  PERS  4413S. 

•  Verify  Members  (filtered)  -  Displays  members  where  their  designators  are 
not  like  510x,  653x,  753x.  This  shows  all  non-CEC  type  members. 

•  All  Members  -  This  is  the  catch  all  review  for  the  Community 
Management  Analyst.  From  this  screen,  he  can  review  all  imported 
member  data. 

•  Members  Without  Matching  Activity  -  After  cleaning  up  the  member 
data,  this  screen  will  show  those  remaining  members  who  do  not  have  a 
matching  activity  (UIC).  The  user  can  modify  the  member’s  activity 
(UIC)  and  billet  (BSC),  delete  the  member,  move  the  ultimate  duty  station 
information  to  the  current  duty  station  information,  or  add  a  new  activity 
and  billet  for  that  member. 

•  Members  Without  Matching  Billets  -  Once  all  members  have  been 
correctly  associated  with  an  activity,  this  form  checks  to  see  if  their 
current  billet  information  matches  a  billet  listed  for  that  activity.  The  user 
can  fix  whatever  information  is  necessary  and  then,  when  satisfied,  click 
the  button  to  add  the  remaining  missing  billets  to  the  billet  table. 


Figure  13.  Member  Data  Cleanup  Form 
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2.  CEC  Member  Management 

The  heart  of  the  GUI  is  located  in  the  CEC  member  management  section.  The 
user  works  off  the  member  management  switchboard  shown  below  in  Figure  14. 


Figure  14.  CEC  Member  Management  Switchboard 
This  switchboard  supports  two  main  actions — Update  Members  and  Update 
Activities  and  Billets.  The  user  is  able  to  navigate  through  the  application  to  add,  update, 
and  delete  billets,  activities,  and  members.  These  forms  also  provide  functionality  for 
assigning  new  orders  to  a  member  or  modifying  existing  ones. 
a.  Member  Update  Form 

The  member  update  form  is  shown  below  in  Figure  15. 
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Figure  15.  Member  Update  Form 

From  this  form,  the  user  can  modify  a  member’s  name,  social  security 
number,  designator,  subspecialty  code  (P-Code),  year  group,  race,  sex,  and  nickname. 
Also  located  on  this  form  are  all  the  professional  qualifications  the  member  has  obtained 
as  well  as  the  member’s  duty  preferences.  Other  information  that  is  listed,  but  not 
editable  on  the  screen,  is  the  member’s  current  and  ultimate  duty  stations.  Additional 
personal  information  as  well  as  the  member’s  billet  history  is  located  on  the  next  screen 
(Figure  16)  and  accessed  by  pushing  the  View/Modify  Member  Details  button. 
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E!  Update  Member  Details 
Name  LT  WEINSTEIN.  BRIAN  LOUIS 


Nick  Name 
Home  Address 
Home  Address 
Home  City: 
Home  State: 
Home  Zip: 
Work  Email 
Home  Email 
Alt.  Email 


21 4  Metz  Rd 


Seaside 


blweinst@nps.  navy,  mil 


brian@dontbotherme.  com 


Phone 

(•  US  f  International 


Home 

Cell 

Work 

Work  (DSN) 
Pager 


|(000]  867-5309 


|(000)  555-5555 
1 765-5555 


Can't  find  the  right  billet  or  activity? 
Create  a  new  one  here: 

New  Billet  | 


Billet  History 


17]  i  )  Recoid  1266  oM342  »  |  H  |  H*  | 


Figure  16.  Additional  Member  Details  Form 
Member  information  including  address,  phone  numbers,  and  email  can  be 
input  or  modified  on  this  screen.  Additionally,  the  user  can  input  new  duty  stations  for 
members  (issue  orders),  delete  a  duty  station,  or  modify  the  existing  ones.  The  user 
selects  the  UIC  drop-down  combination  box  to  find  the  right  combination  of  UIC  and 
BSC  for  the  member.  Values  for  the  UIC  can  also  be  typed  into  the  combination  box  to 
narrow  down  the  search  for  the  correct  billet.  Billet  and  activity  information  cannot  be 
modified  from  this  screen.  If  the  desired  billet  assignment  does  not  exist,  the  user  must 
create  the  billet  and/or  activity  from  the  provided  command  button  on  the  form. 


An  alternative  to  assigning  the  member  a  new  billet  in  Figure  16  is  to  click 
the  Assign  New  Orders  button  from  Figure  15.  This  brings  up  a  small  window,  shown 
below  in  Figure  17,  specific  to  the  member  on  the  main  form.  Selecting  the  UIC  for  the 
new  orders  will  automatically  filter  the  activity  list  to  show  only  those  in  that  UIC.  Once 
the  activity  is  selected,  only  billets  that  are  attached  to  that  activity  will  appear  on  the 
BSC  drop-down  menu.  The  user  completes  the  form  by  filling  in  the  appropriate  dates 
and  billet  status  and  clicks  the  Assign  Member  button  to  complete  the  process. 
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Figure  17.  New  Orders  Assignment  Form 
b.  Activity  /Billet  Update  Form 

Activity  information  is  not  imported  from  any  existing  production 
systems.  The  ACTIVITY  table  was  populated  from  the  old  P-1  database  and  must  be 
maintained  by  the  Community  Management  Analyst  to  ensure  that  the  billets  and  bodies 
match  up  with  the  correct  activity.  Activity  data  is  maintained  using  the  Activity 
Management  form  shown  below  in  Figure  18. 


Figure  18.  Activity  /  Billet  Management  Form 


Since  billets  cannot  exist  without  an  activity,  it  logically  follows  that  the 
billets  should  be  maintained  on  the  same  form  as  the  activity.  This  makes  it  easier  for  the 
user  to  search  for  a  billet  by  first  selecting  the  activity  to  which  it  belongs. 
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3.  Background  Data  Management 


Background  data  is  the  supporting  information  in  a  database  for  the  main  entities. 
It  can  be  in  the  form  of  related  tables  or  lookup  tables.  This  data  serves  two  purposes. 
The  first  is  to  ensure  data  consistency  throughout  the  database.  For  example,  there  are 
several  different  ways  to  notate  a  member’s  rank.  A  Lieutenant  could  be  listed  as  LT, 
Lt.,  Lieutenant,  03,  0-3,  etc.  By  creating  a  lookup  table  of  allowed  values,  the 
application  now  limits  the  end-user  to  one  standardized  format.  The  second  purpose  is  to 
make  data  entry  easier  for  the  user.  With  a  lookup  table,  a  user  can  select  an  allowed 
value  from  a  drop-down  list  instead  of  manually  typing  in  the  entry.  The  problem  with 
having  lookup  tables  is  that  over  time,  the  allowed  values  could  change.  For  example,  P- 
Codes  are  listed  in  a  lookup  table  and  it  is  conceivable  that  a  new  P-Code  will  be  created, 
another  deleted,  and  others  modified.  To  support  these  changes,  a  user  must  be  able  to 
modify  the  background  data.  An  example  of  the  background  data  management  form  is 
shown  below  in  Figure  19.  This  form  allows  the  user  to  modify  the  four  main 
background  data  lookup  tables. 

na  Manage  Background  Data  I  -  1 

Dehiyndtur  Qualifications;  |  P-Codss  Ranks; 


Update  DcciqMtot  Information 


Designator 

Description 

SoftOrtfer 

► 

m 

ACTIVE  DUTY  CML  ENGINEER  CORPS  OFFICER 

0 

5105 

ACTIVE  DUTY  RESERVE  CIVIL  ENGINEER  CORPS  OFFICER 

10 

6530 

CIVIL  ENGINEER  CORPS  LIMITED  DUTY  OFFICER  (LOO} 

20 

6531 

OVIL  ENGMEER  CORPS  UMITEO  DUTY  OFFICER  (LDO) 

30 

6532 

CIVIL  ENGINEER  CORPS  LIMITED  DUTY  OFFICER  (LDO) 

40 

7531 

CML  ENGHEER  CORPS  CHIEF  WARRANT  OFFICER  (CWOf 

so _ 

7535 

CML  ENGINEER  CORPS  CHIEF  WARRANT  OFFICER  (CWO; 

60 

7530 

CML  ENGINEER  CORPS  CHIEF  WARRANT  OFFICER  (CWO| 

70 

- 

1000 

URL  OFFICER  BILLET 

» 

1050 

URL  BILLET  REQUIRING  AN  OFFICER  QUAIFIED  IN  A  WARFARE  SPECIALTY 

78 

1110 

SURFACE  WARFARE  QUALIFIED  URL  OFFICER 

6D 

1115 

SURFACE  WARFARE  QUALIFED  URL  OFFICER  (RESERVE) 

90 

1120 

SUBMARINE  WARFARE  QUALIFIED  URL  OFFICER 

100 

1125 

SUBMARINE  WARFARE  QUALIFIED  URL  OFFICER  (RESERVE) 

110 

1165 

URL  OFFICER  IN  TRAINING  FOR  SURFACE  WAFiFARE  QUALIFICATION 

120 

1175 

URL  OFFICER  IN  TRAINING  FOR  SUBMARINE  WARFARE  QUALIFICATION 

130 

1310 

URL  OFFICER  QUALIFIED  AS  A  NAVAL  AVIATOR 

140 

1315 

URL  OFFICER  QUALIFIED  AS  A  NAVAL  AVIATOR 

150 

1320 

URL  OFFICER  QUALIFIED  AS  A  NAVAL  FLIGHT  OFFICER 

160 

1390 

URL  OFFICER  IN  TRAINING  AS  A  NAVAL  AVIATOR 

170 

1395 

URL  OFFICER  IN  TRAINING  AS  A  NAVAL  AVIATOR 

180 

* 

0 

Record;  Mill  T  ►  I  H  iHfl  of  21 


Figure  19.  Background  Data  Management  Form 
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4.  Report  Viewing 

The  two  main  reports  for  the  detailers  are  the  Staffing  Plan  and  the  P-1.  The 
Staffing  Plan  is  used  to  help  the  detailers  determine  where  CEC  members  are  stationed 
and  where  they  will  be  going  for  their  next  duty  station  at  a  projected  date.  Typically,  the 
Staffing  Plan  is  generated  looking  three  months  in  advance,  taking  the  personnel  who 
have  ultimate  duty  stations  with  reporting  dates  that  fall  into  that  window  and  placing 
them  in  their  new  duty  station  for  the  purposes  of  the  report.  The  P- 1  is  generated  in  the 
same  manner  with  a  projection  date  applied  to  ensure  the  data  is  valid  for  several  months 
after  the  report  is  published.  A  sample  of  the  Staffing  Plan  is  shown  below  in  Figure  20. 
Note  that  the  actual  data  has  been  masked  to  protect  the  member’s  privacy  and  security. 
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Figure  20.  Sample  Staffing  Plan 

The  P- 1  has  three  components — a  personnel  listing,  a  detailed  command  listing 
with  personnel,  and  a  simple  command  listing.  These  are  displayed  in  Figures  21-22 
below.  Again,  actual  data  has  been  masked  to  protect  the  privacy  and  security  of  the 
members. 
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Figure  21.  P-1  Personnel  Listing 
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Figure  22.  P- 1  Billets  Sample 
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Figure  23.  P-1  Command  Listing  Sample 

An  additional  report  that  was  requested  and  created  for  the  users  is  a  report 
showing  members  with  a  particular  rank  and  PRD.  The  users  are  presented  with  a  form 
in  which  they  will  fill  out  their  desired  PRD  and  what  ranks  they  would  like  to  see  in  the 
report.  The  form  allows  for  a  maximum  of  three  ranks  to  filter  for  because  a  three  rank 
range  is  typically  all  one  particular  detailer  will  care  to  examine.  The  form  and  report  is 
shown  below  in  Figures  24  and  25. 


Figure  24.  Filter  Form  for  Member  By  Rank  and  PRD  Report 
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CEC  Members  by  Rank  and  PRD 

FOR  OFFICIAL  USE  ONLY 

PRD  by  Month  April  2001 

Rank  Member  Name 

Activity  Name 

Bilet  Tide 

Rpt  Date 

PRD 

LT  LastNamc  First  Middle 

ENOFLEMCT  MW  GREAT  LAKES  IL 

FAC  CONST  SVC  ARCTCC 

0103 

0104 

PRD  by  Month  Jots  2001 

Rank  Member  Name 

Activity  Name 

Bilet  Tide 

Rpt  Date 

PRD 

LT  l  astNaror  First  Middle 

NROTCUUNW  CF  ILLINOIS  CHAMPA 

STUDENT 

0103 

010S 

PRD  by  Month  April  2002 

Rank  Member  Name 

Activity  Name 

Bilet  T  ide 

Rpt  Date 

PRD 

LT  I  iutNamr  First  Middle 

SOUTHXY  CCNT  CFC  BILOXI  MS 

FAC  CONST  SVC  ARCKC 

0109 

0204 

LT  LastNamc  First  Middle 

H^NDiYPMBOS  SEKYEES  WAS  D 

PttORBGCNAL.APttO 

0103 

0204 

PRD  by  Month  May  2002 

Rank  Member  Name 

Activity  Name 

Bilet  Tide 

Rpt  Date 

PRD 

LT 

NAYSECGRUACT  SAB  ANA  SEC  A  PR 

0103 

0X5 

PRD  by  Month  August  2002 

Rank  Member  Name 

Activity  Name 

Bilet  Tide 

Rpt  Date 

PRD 

LT  LastNamc  First  Middle 

SEPARATING  OFFICERS 

020S 

0X8 

LT  LastNamc  First  Middle 

NMCB  ONE  THF.TY-T  HREE 

TRAINING 

0005 

0X8 

LT  l  utNainr  First  Middle 

CCUNAVTOB.  SEOUL  KOREA 

FAC  ENG 

C0CS 

0208 

LT  LastNamc  First  Middle 

NAVUFAC  PACNCRTCST  BANGCR 

STFCIYENG 

0008 

0X3 

PRD  bv M onth  September  2002 

Rank  Member  Name 

Activity  Name 

Bilet  Tide 

Rpt  Date 

PRD 

LT  liutNuiir  First  Middle 

RaCC  SEWELLS  POINT  VA 

FAC  CONST  SYC  ARaCC 

0103 

0209 

LT  LastNamc  First  Middle 

EFACHES  C  ONAS  PATUXENT  RIVE 

FAC  CONST  SVC  ARQCC 

9905 

0209 

LT  UttNamr  First  Middle 

SOUTHXY  CO  BEAUFORT  PCRT  ROY  FAC  CONST  SVC  ARQCC 

:  ; 

0209 

LT  LastNamc  First  Middle 

SEPARATING  OFFICERS 

0209 

0209 

LT  LastNamc  First  Middle 

NATNAYMEDCCW  BEIHESDA.MD 

FAC  ENGASST  STF  CIV  ENG 

0009 

0209 

LT  LastNamc  First  Middle 

CCMUS NAY  CENT  BAHRAIN 

STFPLN 

0109 

0209 

U  Last  Name  First  Middle 

1WC  S.ANDIEGOCA 

FAC  ENGFLAGHCUSING 

0009 

0209 

LT  LastNamc  First  Middle 

KATCURFYAECENEXY  INELANHEAD  PWHW 

9911 

0209 

PRD  byMonth  October  2002 

Rank  Member  Name 

Activity  Name 

Bilet  Tide 

Rpt  Date 

PRD 

LT  LastNamc  First  Middle 

NMCB  FORTY 

CMPNYOFFNCF 

0010 

0210 

LT  LastNamc  First  Middle 

NFESC  ECDET  WNYWASH  DC 

FAC  CONST  SVCOCEANCCNST 

0010 

0210 

LT  FastNarac  First  ^ddlc 

CBUFOUR  ZEROONE GREAT  LAKES 

accBU 

0010 

0210 

LT  LastN sme  First  Middle 

ENGFLDACT  mediterranean  nap 

FAC  COST  SVC  HOST  NATION 

0010 

0210 

LT  LastNamc  First  Middle 

CNSWC  EET  S  TENNIS  SP.ACE  CENTE 

FACHLN&PGM 

0X1 

0210 

LT  LastNamc  First  Middle 

EEELANGSCCL  MONTEREY  CA 

STUDENT 

0204 

0210 

PRD  by  Month  November  2002 

Rank  Member  Name 

Activity  Name 

Bilet  Tide 

Rpt  Date 

PRD 

LT  LastNamc  First  Middle 

EFANECONT  CFC  LAKEHURST  NT 

FAC  CONST  SVC  ARCICC 

0111 

0211 

LT  LastNamc  First  Middle 

NAVSUHFAC  DIEGO  GARCLA. 

P'YMTN 

0111 

0211 
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Figure  25.  CEC  Members  with  Rank  =  LT  and  PRD  <=  12/31/2002 
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Another  useful  report  is  one  showing  CEC  Members  who  have  a  particular 
qualification  and  rank.  The  users  can  select  up  to  three  ranks  and  one  qualification  in  a 
form  similar  that  in  Figure  24. 


CEC  Members  by  Rank  and  Qualification 

FOR  OFFICIAL  USE  ONLY 


Member  by  Rank  LTJG 


Rank 

Meni>er  Name 

Qtal 

Code 

Abbrv 

Description 

LTJG 

lailNmic  First  Middle 

930 

sew 

SEABEE  COMBAT  WARFARE  QUALIFIED  CFTICER 

LTJG 

l^tName  First  Middle 

960 

sew 

SEABEE  COMBAT  WARFARE  QUALIFIED  CFTICER 

LTJG 

lattNmif  First  Middle 

930 

sew 

SEABEE  COMBAT  WARFARE  QUALIFIED  CFTICER 

LTJG 

1-astNanie  First  Middle 

930 

sew 

SEABEE  COMBAT  WARFARE  QUALIFIED  CFTICER 

LTJG 

laitNimf  First  Middle 

930 

sew 

SEABEE  COMBAT  WARFARE  QUALIFIED  CFTICER 

LTJG 

Last.Name  First  Middle 

930 

sew 

SEABEE  COMBAT  WARFARE  QUALIFIED  CFTICER 

LTJG 

laitNanif  First  Middle 

930 

sew 

SEABEE  COMBAT  WARFARE  QUALIFIED  CFTICER 

LTJG 

lattNimr  First  Middle 

930 

sew 

SEABEE  COMBAT  WARFARE  QUALIFIED  CFTICER 

LTJG 

l^stNamr  First  Middle 

930 

sew 

SEABEE  COMBAT  WARFARE  QUALIFIED  CFTICER 

LTJG 

laitNimr  First  Middle 

930 

sew 

SEABEE  COMBAT  WARFARE  QUALIFIED  CFTICER 

LTJG 

lattNimr  First  Middle 

930 

sew 

SEABEE  COMBAT  WARFARE  QUALIFIED  CFTICER 

LTJG 

l^«t\sne  First  Middle 

930 

sew 

SEABEE  COMBAT  WARFARE  QUALIFIED  CFTICER 

LTJG 

lattNmc  First  Middle 

930 

sew 

SEABEE  COMBAT  WARFARE  QUALIFIED  CFTICER 

LTJG 

laitNinir  First  Middle 

930 

sew 

SEABEE  COMBAT  WARFARE  QUALIFIED  CFTICER 

LTJG 

l^astName  First  Middle 

930 

sew 

SEABEE  COMBAT  WARFARE  CUALFIED  CFTICER 

LTJG 

laitNimt  First  Middle 

930 

sew 

SEABEE  COMBAT  WARFARE  QUALIFIED  CFTICER 

LTJG 

1-astName  First  Middle 

930 

sew 

SEABEE  COMBAT  WARFARE  QUALIFIED  CFTICER 

LTJG 

l-astNamr  First  Middle 

930 

sew 

SEABEE  COMBAT  WARFARE  QUALIFIED  CFTICER 

LTJG 

laitNmr  First  Middle 

930 

sew 

SEABEE  COMBAT  WARFARE  QUALIFIED  CFTICER 
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Figure  26.  Members  by  Rank  and  Qualification 
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D.  PERSONALIZATION  &  CUSTOMIZATION 

The  database  application  has  one  primary  user  (CEC  Community  Management 
Analyst)  and  four  secondary  users  (CEC  detailers).  The  application  interface  shown  in 
the  section  above  is  primarily  designed  for  the  Community  Management  Analyst  to  help 
him  prepare  the  Staffing  Plan  and  the  P-1.  Other  reports  and  queries  are  done  in 
anticipation  of  the  CEC  detailers’  needs,  but  further  study  and  analysis  is  required  to 
tailor  the  application  for  their  specific  needs. 

E.  TRAINING  PLAN 

Converting  to  a  new  system  requires  that  the  end-users  be  trained  and  provided 
with  documentation  that  guides  them  through  using  the  new  system.  There  are  many 
philosophies  on  how  training  should  be  conducted.  Some  prefer  one-on-one  training  and 
others  prefer  group  training.  Advocates  of  group  training  say  that  it  is  a  better  use  of  the 
trainer’s  time  and  the  students  will  actually  leam  more  from  each  other  than  from  the 
instructors.  Group  training  can  take  advantage  of  the  ripple  effect  of  education.  The  first 
group  of  trainees  can  then  train  additional  groups  (train  the  trainer).  Proponents  for  one- 
on-one  training  say  that  nothing  beats  the  personalized  experience  of  having  the 
instructor  sit  right  at  the  students’  desk  and  help  them  through  the  program  as  they  try  to 
execute  their  job  with  the  new  system.  The  work  environment  is  familiar  for  the  user  and 
situations  encountered  are  real  instead  of  theoretical. 

Based  on  my  personal  experiences  with  implementing  new  software  programs,  I 
believe  a  combination  of  these  two  techniques  is  the  best  solution  for  the  users.  The 
training  will  be  conducted  in  three  phases — user  orientation,  group  training,  and 
individual  training. 

1.  User  orientation 

In  this  phase,  the  users  will  be  presented  with  the  user  manual  from  the  previous 
section  in  this  chapter.  The  users  will  be  encouraged  to  read  the  manual  thoroughly  and 
then  be  given  a  copy  of  the  application  for  their  free  use.  They  will  be  encouraged  to 
open  up  the  application  and  play  around  with  it  just  to  familiarize  themselves  with  the 
interface  and  its  features.  Some  users  will  quickly  leam  the  application  and  be  able  to 
produce  the  information  they  need  right  away.  Others  will  require  more  instruction  to 
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understand  the  application  completely.  Since  they  will  be  using  a  local  copy  of  the 
application,  they  will  not  be  concerned  with  making  any  data  mistakes.  This  “first  look” 
will  prepare  the  users  for  the  group  training  session  in  the  next  phase  and  should  generate 
questions  about  its  use. 

2.  Group  Training 

In  this  phase,  the  users  will  be  gathered  for  a  formal  introduction  to  the 
application.  The  application  will  be  demonstrated  to  them  and  they  will  follow  along  on 
their  own  machines  during  the  process.  Questions  generated  from  the  first  phase  as  well 
as  the  group  training  will  be  addressed.  The  intent  of  this  session  is  to  provide  an 
overview  of  the  application  and  everything  that  it  can  do  for  the  users.  Detailed  questions 
that  require  more  time  to  answer  will  be  deferred  to  the  individual  sessions  in  the  third 
phase. 

3.  Individual  Training 

The  final  phase  of  training  will  be  conducted  at  each  individual  user’s  desktop. 
After  having  sufficient  time  to  work  with  the  program  individually,  the  user  will  have 
generated  several  questions  on  features  that  are  not  working  in  the  expected  manner, 
desired  features,  and  basic  operations.  The  intent  of  the  individual  training  is  to  address 
any  questions  or  issues  the  user  may  have  and  to  focus  more  in  depth  on  that  particular 
user’s  job  and  how  the  application  can  support  the  user.  The  trainer  will  sit  with  the  users 
as  they  perform  some  of  their  tasks  with  the  application  and  answer  any  questions  as  well 
provide  advice  on  the  use  of  the  application. 

The  goal  of  this  training  plan  is  to  make  the  end-users  as  comfortable  with  the 
application  as  possible.  The  more  comfortable  the  users  are  with  the  system,  the  more 
likely  it  is  that  they  will  use  it  and  demand  similar  functionality  in  the  production 
systems. 

F.  PROTOTYPE 

Traditionally,  physical  design  has  been  a  paper- and-pencil  process.  The  designers 
would  draw  pictures  that  depicted  the  layout  or  structure  of  outputs,  inputs,  and  the  flow 
of  the  application.  This  approach  is  prone  to  errors  and  omissions,  which  can  cause 
problems  in  the  development  of  the  application.  Modem  approaches  are  turning  to 
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prototyping.  A  prototype  is  a  first  full-scale  and  usually  functional  form  of  an 
application.  The  prototyping  approach  is  an  iterative  process  involving  a  close  working 
relationship  between  the  designer  and  users.  (Whitten  1998,  pg.  315)  Prototyping  has 
several  advantages  and  disadvantages  which  were  discussed  in  Chapter  II. 

The  initial  prototypes  for  this  project  focused  mainly  on  the  data  import  from  the 
delimited  text  files.  Working  closely  with  the  Community  Management  Analyst,  the  data 
was  mapped  into  the  new  schema  and  tested  to  ensure  that  the  automated  cleanup 
routines  were  working  properly  and  all  data  was  brought  in  correctly.  This  process 
required  several  iterations  before  the  import  portion  was  finalized.  Without  the  close 
communication  with  the  Community  Management  Analyst,  the  import  data  functions 
would  have  missed  the  mark  considerably.  The  corporate  knowledge  held  by  PERS 
4413S  was  vital  to  the  success  of  the  data  import  and  cleanup  routines. 

After  the  data  was  correctly  imported,  the  focus  turned  to  managing  the  data 
within  the  database  and  pulling  the  information  out  in  a  logical  manner.  Since  most  of 
the  data  management  was  straightforward,  the  prototype  iteration  for  this  portion  went 
quickly.  After  a  few  adjustments  from  the  initial  design,  the  requirements  for  the  data 
management  interface  were  met. 

The  final  portion  of  the  prototype  is  the  generated  reports,  specifically  the 
Staffing  Plan  and  P- 1 .  Because  of  the  partially  normalized  data  model,  some  portions  of 
these  reports  could  not  be  made  exactly  as  their  predecessors.  All  the  information  is  on 
the  reports  but  in  a  slightly  different  format.  The  reports,  as  shown  in  the  GUI  section  of 
this  chapter,  are  in  their  final  state  based  on  feedback  from  the  users.  Whether  the  CEC 
detail  shop  will  use  these  reports  is  still  being  decided.  Hie  format  of  the  Staffing  Plan 
has  been  approved,  but  the  format  of  the  P-1  is  still  being  considered.  Since  this 
publication  goes  to  every  CEC  officer,  there  are  larger  considerations  on  how  the  report 
is  displayed.  All  other  reports  have  been  reviewed  and  modified  according  to  the 
expressed  desires  of  the  detailers. 
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G. 


BETA  TESTING  OF  THE  APPLICATION 


The  beta  test  of  a  system,  sometimes  referred  to  as  validation  testing,  runs  the 
system  in  a  live  environment  using  real  data.  This  validation  tests  for  a  number  of  items. 
(Whitten  1998,  pg.  568) 

•  Systems  performance  -  Does  the  application  respond  in  a  timely  manner 
to  processing  requests? 

•  Systems  performance  at  peak  workload  conditions  -  How  does  the  system 
respond  when  all  users  are  accessing  the  application  at  the  same  time? 

•  Human  engineering  test  -  Is  the  application  as  easy  to  leam  and  use  as 
expected?  Are  there  enhancements  that  could  be  made? 

•  Methods  and  procedures  test  -  During  the  test,  do  the  methods  and 
procedures  in  the  application  support  the  users’  requirements? 

•  Backup  and  recovery  testing  -  Are  procedures  in  place  for  backup  and 
restoration  of  the  system  in  case  of  a  catastrophic  data  loss?  What  is  the 
required  response  time  and  actual  response  time  during  a  simulated 
disaster? 

Due  to  scheduling  conflicts,  the  beta  test  of  this  system  has  not  occurred  as  of  the 
time  of  this  writing.  Although  not  desirable  and  barring  any  major  problems,  the  beta  test 
and  implementation  may  be  conducted  in  one  trip  for  several  reasons  including  time 
constraints  and  funding.  To  minimize  the  risks  of  conducting  a  beta  test  and 
implementation  at  the  same  time,  thorough  alpha  testing  of  the  application  has  been 
completed  with  all  discovered  problems  fixed.  Alpha  testing,  sometimes  referred  to  as 
verification  testing,  runs  the  system  in  a  simulated  environment  using  simulated  data. 
Since  the  application  is  relatively  small,  the  beta  test  will  occur  on  the  first  day  and  the 
results  will  be  evaluated  for  the  criteria  outlined  above.  If  there  are  no  major  problems, 
the  implementation  and  training  will  occur  starting  on  the  next  day.  If  problems  do  arise 
which  require  more  time  to  address,  the  implementation  will  be  pushed  back  to  allow 
time  to  fix  any  problem  areas  of  the  application. 

H.  EVALUATION  OF  ENTIRE  SYSTEM 

The  final  step  prior  to  implementation  of  the  system  is  to  ensure  that  all  the  pieces 
necessary  for  the  entire  system  are  installed  and  working  properly.  For  the 
implementation  of  a  Microsoft  Access  application,  some  of  these  steps  are  not  as  crucial 
as  they  would  be  if  we  were  dealing  with  a  large  enterprise  system. 
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1. 


Installation  of  DBMS 


Access  comes  with  its  own  DBMS  integrated  into  the  application  itself,  so  there  is 
no  requirement  to  install  the  DBMS  separately.  The  data  and  procedures  will  be  placed 
on  the  centralized  file  server  that  is  shared  only  by  the  CEC  detail  shop.  Each  user  will 
need  an  ODBC  (Open  Database  Connectivity)  client  installed  on  their  computer  that  links 
to  the  central  database. 

2.  Create  the  Database 

Since  Access  integrates  the  DBMS  with  the  database,  there  is  no  need  to  create 
the  database  separately.  Other  products  such  as  Oracle  or  Microsoft  SQL  Server  would 
require  a  separate  installation  of  the  DBMS  followed  by  the  creation  of  the  database, 
which  would  be  run  from  the  DBMS. 

3.  Load  and  Convert  the  Data 

Once  the  database  and  clients  are  installed,  the  end-user  must  run  the  procedures 
outlined  in  Chapter  V,  Section  C.  When  the  end-user  has  been  satisfied  that  all  the  data 
has  been  loaded  and  converted,  the  application  is  ready  to  be  tested  and  tuned.  In  larger 
scale  systems,  the  database  programmer  or  administrator  would  typically  handle  the 
loading  and  converting  of  the  data.  For  this  application,  the  data  import  has  been 
partially  automated  for  the  users  to  perform  themselves. 

4.  Test  and  Fine-tune  the  Database 

With  the  data  loaded  and  ready  for  use,  the  users  and  database  developers  must 
now  put  the  application  through  its  paces  to  find  any  areas  where  there  are  performance 
or  data  problems.  These  problems  will  be  evaluated  and  potential  solutions  will  be 
proposed  for  implementation.  Once  solutions  have  been  agreed  upon,  the  database  will 
be  modified  to  accommodate  the  changes  and  then  tested  again  to  ensure  the  changes 
achieve  the  desired  results. 

5.  Evaluate  the  Database  with  the  Application 

In  larger  enterprise  systems,  the  database  and  application  are  typically  separate 
components  of  the  entire  system.  The  interaction  between  these  two  components  is 
critical  to  the  success  of  the  project.  If  the  database  response  lime  is  too  slow  or  the 
application  is  poorly  configured,  the  users  will  become  frustrated  with  the  program  and 
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may  abandon  it  for  their  previous  system.  When  using  an  Access  solution,  some  of  the 
same  issues  can  also  arise  on  a  smaller  scale.  The  GUI  front-end  can  have  the  same 
problems  interacting  with  the  data  as  larger  systems  even  though  the  application  and 
database  are  more  tightly  integrated.  A  full  system  test  of  all  procedures  and  methods 
helps  to  bring  out  any  of  these  potential  performance  and  data  issues.  A  system  test  was 
conducted  thoroughly  during  the  alpha  testing  phase  with  no  major  problems  found. 
Some  minor  problems  in  the  user  interface  were  found  and  repaired  during  this  phase. 
Another  system  test  will  be  conducted  during  the  beta  testing  phase. 

After  all  these  steps  have  been  completed  to  the  satisfaction  of  both  the  end-users 
as  well  as  the  system  designers,  the  application  is  ready  to  be  implemented  in  a  live  data 
environment.  There  are  several  different  strategies  to  consider  when  implementing  a  new 
system  that  replaces  an  older  one. 

I.  GO-LIVE  IMPLEMENTATION 

The  go- live  implementation  of  any  new  system  can  be  a  nervous  time  for  all 
parties  involved.  Several  strategies  are  commonly  used  to  make  the  transition  as  smooth 
as  possible  for  the  end-users  as  well  as  the  support  staff  that  will  be  maintaining  the 
application.  These  strategies  include,  but  are  not  limited  to,  the  abrupt  cutover  and 
parallel  conversion. 

1.  Abrupt  Cutover 

Sometimes  referred  to  as  the  cold- turkey  method,  this  strategy  picks  a  certain  date 
(usually  a  date  that  coincides  with  a  significant  milestone  for  the  organization  such  as  the 
end  of  a  fiscal  year)  to  shut  off  the  old  system  and  implement  the  new  system  on  the  same 
day.  Users  will  no  longer  have  the  option  to  use  the  old  system  and  all  inputs  will  be 
done  through  the  new  system.  There  is  inherent  risk  in  this  method  in  that  the  new 
system  could  have  some  latent  flaw  that  does  not  become  apparent  until  the  system  has 
been  in  use  for  a  business  period.  With  no  backup  system,  the  organization  must  work  to 
figure  out  the  solution  for  the  flaw.  On  the  other  hand,  the  transition  costs  are  minimal, 
as  both  systems  do  not  have  to  be  supported  at  the  same  time. 
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2. 


Parallel  Conversion 


Under  this  approach,  both  the  old  and  the  new  systems  are  operated  for  a 
specified  time.  This  is  done  to  ensure  that  any  major  problems  that  are  discovered  are 
solved  prior  to  dropping  the  old  system.  The  final  cutover  may  be  abrupt  or  gradual,  as 
portions  of  the  new  system  are  deemed  adequate.  This  strategy  minimizes  the  risk  of  the 
new  system  causing  irreparable  damages  to  the  business;  however,  it  also  means  the  cost 
of  the  transition  will  be  significant  because  both  systems  must  be  maintained.  System 
performance  could  also  be  an  issue  if  both  systems  are  competing  for  the  same  computer 
resources. 

3.  Transition  selection 

For  this  project,  I  recommend  the  abrupt  cutover  for  several  reasons.  This  system 
is  not  being  used  for  official  production  data  but  rather  being  used  as  an  information 
delivery  tool,  which  pulls  the  data  from  existing  production  systems.  The  risk  of  damage 
due  to  a  flaw  in  the  application  is  minimal  as  the  data  can  be  imported  again  at  any  time 
using  either  system.  One  inherent  risk  in  using  the  parallel  transition  that  I  have 
experienced  in  the  past  is  how  the  end-users  react  to  initial  problems  with  the  new 
system.  Many  users  who  get  quickly  frustrated  with  a  new  system  because  it  is  not  like 
their  old  comfortable  system  will  quickly  stop  inputting  information  in  the  new  system 
and  go  back  to  their  comfort  zone  in  the  old  system.  If  the  old  system  is  not  available  to 
go  back  to,  the  users  are  forced  to  learn  how  to  use  the  new  program  effectively. 

In  the  end,  since  this  program  is  not  a  mandatory  production  system  that  must  be 
used  the  decision  to  use  the  system  will  be  up  to  each  individual  user.  My  goal  for  the 
implementation  is  to  get  the  application  in  place  running  efficiently  and  to  train  the  users 
in  its  proper  use.  Once  in  place,  the  decision  on  how  and  when  to  use  the  system  is 
ultimately  up  to  the  users. 

J.  IMPLEMENTATION  SUMMARY 

In  order  to  support  a  multi-user  environment,  the  application  was  split  into  two 
parts.  The  first  part,  which  contains  the  data,  queries,  and  functions,  will  reside  on  a 
shared  drive  in  the  central  file  server  accessible  to  the  CEC  detail  shop.  The  other 
portion  contains  the  GUI,  which  will  reside  on  each  client’s  computer.  In  this  manner,  all 
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users  can  share  the  same  data  while  running  the  application  from  their  desktop, 
minimizing  the  load  on  the  network  by  performing  most  functions  on  the  server  as 
opposed  to  the  client. 

Considerable  effort  was  placed  in  the  creation  of  an  easy  to  use  graphical  user 
interface  for  the  users.  Each  form  is  navigated  to  from  a  central  switchboard  that  steps 
the  user  through  the  process  of  data  import  and  cleansing  as  well  as  data  maintenance. 
The  forms  are  designed  for  ease  of  use  by  providing  drop  down  tables  wherever  possible 
and  a  logical  display  of  the  information. 

Extensive  testing  has  been  completed  at  the  development  site.  Additionally,  the 
key  user  has  tested  the  application  at  the  local  site,  providing  feedback  on  functionality, 
accuracy,  and  errors.  All  known  errors  discovered  in  the  testing  phases  have  been 
corrected,  and  the  application  is  ready  for  a  full  beta  test  followed  by  a  complete 
implementation  at  the  client’s  location.  User  manuals  and  training  will  be  provided 
during  the  implementation  phase  of  the  application.  The  extent  to  which  the  application 
will  be  used  and  how  it  will  be  implemented  is  largely  up  to  the  users.  The  main  factor  in 
this  decision  is  how  easy  it  is  to  import  and  cleanse  the  data.  An  easier  process  will  result 
in  more  use  than  a  more  time  consuming  one. 
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VL  DATA  IMPORT,  CLEANSING  &  SYSTEMS  MANAGEMENT 


A.  DATA  IMPORT  AND  CLEANSING 

The  amount  of  effort  to  clean  up  this  data  is  tremendous  and  cannot  be  easily 
solved.  I  spent  weeks  trying  to  take  the  legacy  data,  import  it  into  Access,  and  clean  it  up 
with  some  automated  routines.  My  efforts  were  slightly  useful  at  best,  as  it  sped  up  the 
process  of  data  cleansing,  but  the  main  problem  of  validation  is  still  there.  The  rules  that 
govern  what  changes  need  to  be  made  to  the  data  are  very  dynamic  and  change  on  a 
regular  basis.  Rules  that  are  good  today  could  be  outdated  and  useless  two  months  from 
now.  The  result  of  this  thesis  is  a  semi- automated  data  import  and  cleansing  mechanism. 
A  process  flow  chart  for  the  data  cleansing  is  shown  below  in  Figure  27.  Once  the  data 
from  the  two  files  has  been  imported  and  cleaned  up  as  much  as  possible,  the  next  step  is 
to  attempt  to  relate  them  to  each  other.  The  Billets  and  Bodies  files  were  imported  and 
cleaned  up  into  the  temporary  tables,  tmpBILLET  and  tmpMEMBER,  respectively. 
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Import  Billets  txt  into 
tmpODISBILLETS 


Modify  UIC/BSC  for  the  following: 
62980/40270  ->  62980/44670 
62477/00400  ->  47689/00400 


62477/00400 

62477/00800 

62477/01760 

57046/05020 

57034/00110 


>  47689/00800 

>  00011/01760 

>  57046/00100 

>  57034/00010 


Add  61463/01 100 
Add  00242/10020 


Transfer  Deleted  Billets  to 
tmpDeletedBillets  and 
Delete  Billets  from 
tmpODISBILLETS 


Do  one  of  3  things: 

a)  Add  Billet  to  the  Exception  Activity 
to  be  addressed  later 

b)  Delete  Billet 

c)  Create  new  Activity  for  the  Billet 


Do  all  Billets  have  ax 
matching  Activity?  , 


Delete  Data  From 
tmpODISBILLETS 


Append  remaining 
Billets  to  tmpBILLET 


Import  Bodies.txt 
into  tmpMEMBER 


Clean  up  Member  Data  By: 

a)  ACC 

b)  USNR 

c)  ADDU 

►  d)  Ultimate  EDA 

e)  Pending  Gains 

f)  No  Orders  Loss 

g  )  Non  CEC  Designator  Members 
h)  All  Members 


Are  there  Do  one  of  3  things: 

Members  with  no~v  Yes  a)  Change  Member's  UIC/BSC 
matching  /  ^  b)  Delete  Member 

\  Activity?  c)  Create  new  Activity/Billet  for  member 


Populate  MEMBER  table 
from  tmpMEMBER  and 

Associate  Billets  to 

No  Are  there  Members 

Add  missing  billets 

associate  to  Billets  and 
Qualifications 

BILLET  table 

\  Billet? 

information 

''Are  there  MEMBERS 
without  matching 
„  MEMBER  BILLET?  ^ 


Assign  Member  to 
•  correct  Billet  or 
delete  Member 


Finished! 


Figure  27.  Data  Import  And  Clean-Up  Process 


1.  Relating  Billets  to  Activities 

At  issue  is  the  definition  of  an  activity.  The  CEC  Detail  shop  defines  an  activity 
differently  than  NAVPERSCOM.  Naval  Personnel  Command  identifies  an  activity  by  its 
Unit  Identification  Code  (UIC).  The  CEC  Detail  shop  further  breaks  down  these 
activities  into  sub -activities.  That  means  for  the  CEC,  several  activities  can  have  the 
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same  UIC.  The  legacy  system  data  contains  information  for  the  UIC  and  BSC  of  both 
billets  and  bodies.  In  this  manner,  one  can  figure  out  which  personnel  are  attached  to 
what  activity.  The  problem  arises  when  one  has  to  figure  out  which  personnel  are 
attached  to  which  sub-activity.  There  is  no  information  in  the  legacy  systems  that  define 
these  sub -activities.  In  the  existing  P-1  database,  this  problem  is  overcome  by  an  already 
established  table  of  activities  with  an  assigned  Command  Sequence  Code  (CSC).  Each 
CSC  is  associated  with  the  UICs  and  BSCs  from  the  legacy  systems.  The  combination  of 
CSC,  UIC,  and  BSC  make  a  unique  activity.  In  order  to  maintain  the  same  list  of 
activities,  I  had  to  duplicate  the  UIC,  BSC,  CSC  combination  from  the  older  system  in 
the  new  system.  I  imported  this  table  into  a  temporary  table  called  tmpCSCCodes.  This 
table  contained  all  the  known  combinations  of  UIC,  BSC,  and  CSC.  The  ACTIVITY 
table  was  created  from  the  previous  P- 1  database  system  and  contained  the  relevant  CSC 
Codes.  In  order  to  relate  BILLETS  to  ACTIVITY,  I  split  the  Activities  into  two  parts, 
Single  UIC  and  Multiple  UIC  Activities.  Single  UIC  Activities  are  those  that  have  only 
one  UIC  and  Multiple  UIC  Activities  are  those  that  have  several  sub -activities  under  one 
UIC.  The  SQL  structure  for  these  two  queries  is  as  follows: 

•  Single  UIC:  SELECT  ACTIVITY.  UIC  FROM  ACTIVITY  GROUP 
BY  ACTIVITY. UIC  HAVING  Count (ACTIVITY . UIC) =1 

•  Multiple  UIC:  SELECT  ACTIVITY. UIC  FROM  ACTIVITY  GROUP 
BY  ACTIVITY. UIC  HAVING  Count  (ACTIVITY . UIC) >1 

The  Single  UIC  Activities  were  easily  matched  up  to  their  respective  billets  by 
using  the  UIC  to  relate  the  imported  billets  to  the  ACTIVITY  table.  These  billets  were 
appended  to  another  temporary  table  called  tmpUICActivityWithtmpBillet.  This  table 
contains  the  UIC,  BilletID,  and  ActivitylD  for  each  billet.  To  match  up  the  Multiple  UIC 
Billets  to  their  respective  Activities,  I  had  to  use  the  tmpCSCCodes  table  to  bridge  the 
gap  between  the  imported  billets  and  their  related  activities.  This  was  accomplished 
through  another  append  query  shown  below  in  Ligure  28. 
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Figure  28.  Associating  Multiple  UIC  Billets  To  Activities 

2.  Relating  Bodies  to  Billets 

The  issues  relating  personnel  to  their  respective  billets  are  similar  to  the  previous 
problem  of  relating  billets  to  activities.  The  information  received  from  the  ODIS  text 
files  on  personnel  contains  a  UIC  and  BSC  for  each  member.  Again,  because  PERS  4413 
does  business  differently,  the  UIC  is  not  a  unique  identifier  for  an  activity.  There  are 
eleven  occurrences  of  multiple  activities  for  a  given  UIC.  The  process  is  relatively  the 
same  regardless  of  whether  the  member  is  in  an  activity  that  has  a  unique  UIC  or  one  that 
shares  the  UIC  with  other  activities.  In  each  case,  a  member  may  have  both  a  current 
billet  and  an  ultimate  billet  listed.  The  current  billet  is  generally  where  the  member  is 
stationed  at  the  time  of  the  data  pull,  and  the  ultimate  billet  information  exists  if  the 
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member  has  orders  for  their  next  duty  station.  This  combination  of  information  breaks 
down  into  the  following  four  cases: 

•  Single  UIC  activity  with  current  billet  information 

•  Single  UIC  activity  with  ultimate  billet  information 

•  Multiple  UIC  activity  with  current  billet  information 

•  Multiple  UIC  activity  with  ultimate  billet  information 

With  both  the  MEMBER  and  BILLET  table  populated,  the  task  here  is  to 
populate  the  intersection  table  MEMBER_BILLET  with  the  correct  information.  A 
graphical  representation  of  the  query  for  single  UIC  activities  (current  billet)  is  shown 
below  in  Figure  29.  Upon  examination  or  the  SQL  statement  (Figure  30)  for  this  update, 
one  will  notice  that  a  function  had  to  be  called  to  convert  the  date  information  from 
tmpBILLET  to  an  acceptable  date/time  format  for  Microsoft  Access.  Since  the  date 
information  in  the  original  data  was  in  a  yyyymmdd  format,  Access  could  not  properly 
interpret  the  string  as  a  date,  especially  because  many  times  the  data  was  in  a  yyyymm 
format  without  the  day  information.  In  order  to  handle  this,  I  created  a  custom  function 
called  ConvertDate  using  Visual  Basic.  This  function  takes  the  string  in  its  current 
format  and  returns  a  valid  date/time  formatted  string.  The  code  for  this  function  and  all 
other  VBA  code  is  located  in  Appendix  H. 


Figure  29.  Associate  Members  to  Billets 
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INSERT  INTO  MEMBER_BILLET  (  MemberlD,  BilletID, 
ReportDate,  PRD,  Type  ) 

SELECT  MEMBER. Member ID,  BILLET . Billet ID, 

ConvertDate ( [tmpMEMBER] ! [ReportDate])  AS  ReportDate, 

Ilf (ConvertDate ( [tmpMEMBER] ! [PRD ] ) =" " , Date Add ( "yyyy " , 2 , Co 
nvertDate ( [tmpMEMBER] ! [ReportDate] ) ) , ConvertDate ( [tmpMEMB 
ER] ! [PRD ] ) )  AS  PRD,  "Current"  AS  Type 
FROM  (ACTIVITY  INNER  JOIN  (MEMBER  INNER  JOIN 
(qrySingleUICs  INNER  JOIN  tmpMEMBER  ON  qryS ingleUICs . UIC 
=  tmpMEMBER. UIC)  ON  MEMBER. SSN  =  tmpMEMBER . SSN)  ON 
ACTIVITY. UIC  =  qrySingleUICs .UIC)  INNER  JOIN  BILLET  ON 
(ACTIVITY. ActivitylD  =  BILLET .ActivitylD)  AND 
(tmpMEMBER. BSC  =  BILLET. BSC); 


Figure  30.  Associate  Members  To  Billets  SQL  Statement 

The  process  for  the  other  three  cases  is  essentially  the  same  with  slight  variances 
on  the  joins  in  the  query  and  which  fields  are  selected  to  be  appended  to  the 
MEMBER_BILLET  table.  The  ultimate  billet  queries  are  joined  on  the  UltUIC  and 
UltBSC  fields  and  the  multiple  UIC  queries  replace  qrySingleUICs  with 
qry  MultipleUIC  s . 

B.  MAINTENANCE  PLAN 

No  matter  how  well  designed,  built,  and  tested  a  system  may  be,  errors  or  bugs 
will  inevitably  occur.  Bugs  can  be  caused  by  a  variety  of  reasons  including,  but  not 
limited  to,  miscommunication  of  requirements,  design  flaws,  unanticipated  situations  that 
were  not  tested,  and  unanticipated  misuse  of  the  programs.  The  challenge  for  every  new 
system  that  has  been  implemented  is  having  a  plan  for  how  to  handle  any  problems  that 
may  come  up. 

1.  Database 

Microsoft  Access  has  a  built-in  tool  for  database  maintenance  that  compacts  and 
repairs  the  database  upon  command.  When  users  delete  data  or  objects  in  an  Access 
database,  the  file  can  become  fragmented  and  use  disk  space  inefficiently.  Compacting 
optimizes  the  performance  of  Access  databases  by  making  a  copy  of  the  file  and 
rearranging  how  the  file  is  stored  on  the  disk.  The  database  can  also  be  set  to  compact 
every  time  the  application  is  closed. 
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In  most  cases,  Microsoft  Access  can  detect  whether  an  Access  file  is  damaged 
when  it  is  opened  and  gives  the  option  to  repair  it  at  that  time.  In  some  situations,  Access 
may  not  detect  that  a  file  is  damaged.  It  is  a  good  idea  to  compact  and  repair  the  database 
on  a  regular  basis.  Access  can  repair  a  corrupted  Access  database  table. 

The  users  will  be  instructed  in  the  proper  procedure  for  compacting  and  repairing 
the  database.  As  mentioned  in  Chapter  II,  the  IT  support  staff  does  not  have  any  plans  to 
support  this  database  application  in  any  manner.  Responsibility  for  the  maintenance  and 
support  of  the  database  will  fall  within  the  Community  Management  Analyst’s  purview. 
He  will  be  responsible  for  ensuring  that  the  data  is  well  maintained  and  if  any  technical 
problems  arise,  he  will  be  the  one  to  try  to  solve  the  problem.  If  the  problem  is  beyond 
his  capacity,  he  also  has  the  ability  to  contact  me  for  support. 

2.  Application 

The  repair  feature  mentioned  above  can  also  help  with  minor  application 
problems  by  fixing  a  problem  with  corruption  in  a  form,  report,  or  module.  The  Access 
repair  function  can  also  fix  missing  information  that  Access  needs  to  open  a  particular 
form,  report,  or  module.  The  database  and  application  should  be  backed  up  on  a  weekly 
basis  in  case  a  crash  occurs  and  causes  irreparable  damage  to  the  application.  For  this 
particular  application,  the  backup  is  a  simple  procedure  of  copying  the  two  files  (database 
file  on  the  server  and  the  GUI  on  the  client)  to  a  CD  that  is  stored  in  a  separate  location 
from  the  server.  The  overall  maintenance  of  Microsoft  Access  is  the  responsibility  of  the 
IT  staff.  They  should  ensure  that  the  users  have  the  latest  software  on  their  machines 
with  all  relevant  patches  installed. 

The  main  objectives  of  system  maintenance  are  two -fold.  The  first  is  to  make 
changes  to  existing  programs  to  correct  errors  that  were  made  during  design  and 
implementation.  Enhancements  and  new  requirements  are  thus  excluded  from  this 
activity.  Future  enhancements  are  addressed  in  Chapter  VII.  Secondly,  system 
maintenance  should  preserve  the  aspects  of  the  program  that  were  already  correct  by 
attempting  to  avoid  the  cases  where  a  “fix”  to  one  area  causes  undesirable  effects  in 
another  area  of  the  system.  Keeping  these  objectives  in  mind,  minor  modifications  will 
be  corrected  in  the  event  errors  or  omissions  are  discovered.  Major  enhancements  as  a 
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result  of  new  requirements  or  customer  desires  will  be  left  for  others  to  accomplish  in  a 
follow-on  project  if  desired. 

C.  SCALABILITY 

1.  Database 

If  the  need  to  expand  to  more  users  grows,  the  database  is  scalable  to  grow  with  it. 
As  more  and  more  users  connect  to  the  database  and  try  to  use  it  in  its  current  state,  the 
application’s  performance  could  degrade.  Applications  that  do  not  scale  well  usually  end 
up  causing  two  problems.  The  first  problem  is  that  the  developer  of  the  application  will 
have  to  spend  more  time  trying  to  get  the  most  out  of  the  database  in  order  to  increase 
performance.  The  second  problem  is  that  the  database  system  is  now  viewed  as 
something  less  than  perfect,  and  the  users  lose  respect  for  the  developer  as  well  as  the 
application  and  may  give  up  on  the  system  in  its  entirety.  A  scalable  solution  is  capable 
of  performing  adequately  even  when  a  larger  than  expected  group  of  people  begin  to  use 
it.  The  key  to  building  a  scalable  application  is  to  minimize  the  amount  of  information 
being  passed  across  the  network  and  preventing  record  contentions  when  multiple  people 
try  to  use  the  same  information. 

The  size  of  the  CEC  detail  shop  is  small  enough  that  one  person  (Community 
Management  Analyst)  can  be  the  administrator  of  the  database  with  the  other  detailers 
only  using  a  local  copy  of  his  database.  There  are  no  current  plans  to  make  this  database 
into  a  production  system  or  grow  its  user  base  beyond  its  current  amount.  Should  the 
desire  exist  to  expand  the  database  to  include  other  surrounding  areas,  then  a  few  key 
changes  would  be  considered: 

a.  Split  the  Database 

One  of  the  options  already  discussed  in  Chapter  V  is  to  split  the  database 
into  two  separate  databases  are  linked  via  an  ODBC  connection.  All  the  forms  are  placed 
in  a  front-end  database  while  the  data  tables,  queries,  reports,  modules,  and  macros  are 
placed  in  a  back-end  database.  Each  client  machine  then  uses  its  own  personal  copy  of 
the  front-end  database  to  interact  with  a  single  copy  of  the  back-end  database  that  is 
located  on  a  central  server,  thus  reducing  network  traffic  for  the  use  of  the  application. 
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Figure  31.  Scalability  -  Split  Access  Database 


b.  Migrate  to  the  Web 

Another  way  to  improve  the  scalability  of  the  application  is  to  use  an 
Access  database  and  a  web  server.  In  this  manner,  anyone  can  communicate  to  the 
central  database  engine  through  Active  Server  Pages  or  any  other  type  of  web  page 
capable  of  interfacing  with  a  database.  This  puts  the  burden  of  running  queries  and 
responding  to  requests  on  the  web  server  and  will  not  tie  up  the  network  as  much  as 
multiple  people  accessing  the  database  application  over  the  network. 

c.  Migrate  to  a  More  Robust  DBMS 

If  neither  of  the  above  is  sufficient,  the  database  can  be  migrated  to  a  more 
robust  Database  Management  Tool  to  handle  a  larger  number  of  simultaneous  users,  such 
as  SQL  Server  or  Oracle.  The  task  of  migrating  an  Access  database  to  a  larger  DBMS  is 
not  that  difficult  and  could  be  done  with  this  particular  database  relatively  simply. 
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2.  Application 

If  the  need  arises,  the  application  itself  could  be  written  in  Visual  Basic  instead  of 
using  Microsoft  Access.  The  application  could  then  interface  with  the  Access  data  tables 
or  another  DBMS  to  provide  functionality  to  the  users.  A  Visual  Basic  program  that 
interfaces  with  a  SQL  server  would  most  likely  give  the  user  the  best  performance  for  the 
application.  The  downside  to  this  solution  is  that  it  requires  much  more  maintenance  and 
oversight  to  keep  the  program  running. 

D.  HUMAN  RESOURCES 

When  implementing  a  new  system,  the  question  of  who  will  maintain  it  is  a  very 
important  one  to  address.  If  there  is  not  anyone  who  is  qualified  and  has  the  time  to  keep 
the  system  running  and  handle  any  problems  with  the  system,  then  the  system  may  be 
doomed  to  failure.  An  analysis  of  the  current  organization’s  staff  and  their  capabilities 
can  go  a  long  way  in  determining  what  type  of  support  the  system  will  have  with  the 
current  staff.  Some  organizations  may  decide  to  hire  a  person  in  direct  support  of  the 
new  application  depending  on  their  needs.  In  the  case  of  the  CEC  detail  shop,  there  are 
not  any  additional  personnel  requirements  to  support  the  new  system.  The  Community 
Management  Analyst  will  be  the  system  administrator  and  handle  any  problems  with  the 
database.  The  IT  staff  will  support  the  detail  shop  by  providing  a  network  to  work  on  and 
the  latest  Microsoft  Office  software. 

E.  TRAINING 

Training  is  not  a  one-time  event  in  the  implementation  of  a  new  system.  The 
CEC  detail  shop  has  a  revolving  door  for  its  military  staff.  Detailers  will  typically  spend 
one  to  two  years  working  in  their  position  and  then  move  on  to  something  else.  Their 
replacements  will  come  into  the  office  with  no  prior  knowledge  of  the  database  system. 
These  replacements  will  need  training  on  how  to  use  the  system.  Each  new  user  will  be 
given  a  copy  of  the  user’s  manual  to  help  them  learn  the  application.  As  discussed  in  the 
training  plan  in  Chapter  V,  the  end-users  will  train  new  personnel  on  the  systems  on  an 
as- needed  basis.  This  training  will  coincide  with  the  turnover  of  duties  from  one  officer 
to  the  other.  The  Community  Management  Analyst  is  a  civilian  employee  who  provides 
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continuity  to  the  office  and  will  be  the  primary  source  of  information  on  the  system  for 
new  users. 

The  detailing  management  system  was  designed  and  built  with  objective  that  it 
would  be  easy  to  use  and  require  minimal  maintenance  for  the  end-users.  With  a  little 
care,  the  end-users  will  be  able  to  use  this  system  effectively  and  efficiently  to  help  them 
manage  the  personnel  for  which  they  are  responsible. 

F.  DATA  IMPORT  AND  MAINTENANCE  SUMMARY 

A  database  is  only  as  good  as  the  data  that  is  in  it.  A  common  expression  in 
database  circles  is  “garbage  in  equals  garbage  out.”  If  the  data  that  is  imported  is  not 
reliable,  then  the  entire  application  is  useless.  Users  will  not  waste  their  time  with  a 
system  that  does  not  provide  them  with  accurate  and  timely  information.  The  data  import 
routines  developed  for  this  application  help  the  users  clean  the  data  to  make  it  as  accurate 
as  possible.  Inconsistency  in  data  formats  are  also  addressed  in  these  routines. 

Ensuring  that  the  data  is  accurate  and  up  to  date  is  just  one  part  of  maintaining  a 
database  application.  The  physical  data  itself  must  also  be  maintained.  Microsoft  Access 
provides  several  simple  methods  to  maintain  the  data  tables  as  well  as  repair  any 
corrupted  tables.  Keeping  the  Microsoft  Access  application  up  to  date  with  the  latest 
recommended  patches  will  also  help  maintain  the  stability  of  the  application. 

To  ensure  that  the  application  will  last  for  a  reasonable  length  of  time,  it  is 
important  to  design  and  build  scalability  into  the  system.  This  application  is  designed 
with  future  growth  and  enhancements  in  mind.  The  system  can  be  migrated  to  a  larger 
DBMS  or  to  the  web  with  relative  ease,  minimizing  the  impact  on  the  users. 

As  CEC  personnel  rotate  in  and  out  of  the  detail  shop,  the  need  for  training  will 
continue.  Easy  to  understand  user  manuals  will  assist  in  this  area  as  well  as  training  from 
current  personnel  during  their  turnover  of  duties.  The  Community  Management  Analyst, 
a  civilian  employee,  provides  continuity  in  the  office  and  will  become  the  resident  expert 
in  the  application. 
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vn.  LESSONS  LEARNED,  RECOMMENDATIONS,  AND 

CONCLUSION 


A.  LESSONS  LEARNED 

In  the  development  of  any  system,  there  are  always  problems  that  arise  and 
mistakes  made.  A  few  specific  problem  areas  have  been  identified  to  avoid  in  future 
developments  of  similar  projects.  The  purpose  of  this  section  is  not  to  identify  every 
problem  area  and  mistake  made  during  the  development  but  to  point  out  key  changes  in 
the  process  that  would  have  streamlined  the  development. 

1.  Ask  the  Right  Questions 

The  most  important  step  in  any  systems  development  is  the  requirements  analysis. 
Key  information  about  the  design  of  the  system  will  be  obtained  through  various 
interviews  with  the  organization.  If  the  analyst  does  not  ask  the  proper  questions  from 
the  appropriate  personnel,  crucial  information  may  be  left  undiscovered  until  late  in  the 
design. 

As  an  example,  the  discovery  of  the  existence  of  the  Navy  Personnel  Database 
(NPDB)  was  not  made  until  one  month  prior  to  the  completion  of  this  thesis.  Linking  the 
new  system  to  a  relational  database  instead  of  downloading  and  importing  separate  text 
files  would  have  made  the  new  system  more  efficient  and  easier  to  use.  Attempts  to  gain 
approval  for  read-only  access  to  the  NPDB  were  unsuccessful.  Had  this  system  been 
discovered  earlier,  the  approval  process  may  have  been  accomplished  and  the  new  system 
could  have  been  designed  to  interact  with  the  NPDB.  Because  the  requirements  analysis 
trip  was  conducted  on  short  notice,  there  was  not  adequate  time  to  prepare  questions  and 
arrange  for  interviews.  Thorough  preparation  and  arrangements  may  have  resulted  in  the 
discovery  of  the  NPDB. 

2.  Avoid  Duplication  of  Existing  Systems 

One  of  the  pitfalls  to  avoid  when  designing  a  new  system  for  an  organization  is  to 
duplicate  the  old  system  in  design  or  functionality.  It  is  very  easy  to  look  at  the  old 
system  and  try  to  recreate  it  in  the  new  system  without  investigating  the  reason  the  old 
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system  was  designed  in  that  manner.  One  area  that  may  be  susceptible  to  duplication  is 
report  generation  and  formatting. 

As  an  example,  the  original  P-1  report  contained  an  index  showing  all  the  CEC 
personnel  with  information  on  their  rank,  year  group,  P-Code,  and  qualifications  earned. 
Since  this  report  was  based  of  a  de- normalized  table,  it  was  easy  to  display  each 
qualification  a  member  had  obtained.  In  the  new  system,  qualifications  are  related  to 
members  in  a  many- to- many  relationship.  This  normalized  structure  makes  it  more 
challenging  to  display  each  member’s  earned  qualifications  on  the  same  row  as  the 
member.  After  considerable  effort,  this  challenge  was  overcome  using  a  cross- tab  query 
and  a  concatenation  statement  to  merge  all  the  qualifications  for  each  member  into  one 
field  for  display  purposes.  Perhaps  the  better  way  to  address  these  types  of  issues  is  to 
return  to  the  customer  and  discuss  the  importance  of  their  report  format.  If  all  the 
information  is  there,  but  displayed  in  a  slightly  different  manner,  then  maybe  the  report  is 
sufficient  for  the  customer’s  needs. 

3.  Familiarize  Yourself  with  A  CASE  Tool  Early  In  the  Process 

When  working  on  any  project,  whether  it  be  building  a  piece  of  furniture  or 
developing  a  software  application,  it  is  crucial  to  have  the  right  tools  for  the  job.  Even 
with  the  right  tools,  the  project  can  be  delayed  or  flawed  if  the  builder  does  not  know 
how  to  use  them  properly.  While  Visible  Analyst  provided  assistance  in  the  development 
of  the  database  model,  the  process  was  not  an  easy  one.  There  was  a  steep  learning  curve 
in  using  the  tool  proficiently. 

For  example,  initial  attempts  to  generate  the  database  schema  in  Access  from 
Visible  Analyst  resulted  in  an  error  message  that  prevented  the  generation  from 
occurring.  Several  days  were  spent  trying  to  resolve  the  problem  and  it  was  finally 
resolved  by  shipping  the  Visible  Analyst  project  and  the  Access  database  to  the  technical 
support  personnel  for  Visible  Analyst.  The  fix  was  a  simple  case  of  incorrectly  entering 
data  into  one  field  on  the  schema  generation  options. 

Another  case  involved  the  creation  of  referential  integrity  constraints  in  the 
Visible  Analyst  project  that  would  transfer  to  the  Access  database  when  exported. 
According  the  user  manual  and  help  documents  in  Visible  Analyst,  this  particular  edition 
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of  the  program  was  capable  of  creating  referential  integrity  constraints  and  exporting 
them  to  Access.  However,  the  check  box  to  create  these  constraints  was  grayed  out  and 
not  selectable.  Without  this  feature  working,  each  time  the  database  schema  was 
exported  to  Access,  I  had  to  manually  add  the  referential  integrity  constraints  in  Access 
for  each  relationship.  Visible  Analyst  technical  support  supplied  a  solution  by  providing 
instructions  on  how  to  modify  one  of  the  program  files  in  Visible  Analyst  to  allow 
referential  integrity  to  work  properly. 

These  problems  caused  some  delay  in  the  development  of  the  prototype  and  could 
have  been  avoided  had  I  been  more  proficient  in  my  understanding  of  the  tool  and  all  its 
features.  Deciding  on  a  tool  to  use  early  on  in  the  project  would  hive  helped  streamline 
the  development  phases  later  on  in  the  project. 

4.  Create  a  Detailed  Project  Plan  Based  on  Methodology 

Development  projects  of  this  nature  can  often  lead  the  developer  in  a  different 
direction  than  what  was  envisioned.  A  detailed  project  plan  based  on  the  methodology 
chosen  can  help  to  keep  the  developer  focused  on  the  task  at  hand.  A  plan  that  identifies 
each  phase  of  the  project  with  every  task  required  to  accomplish  the  phase  included  with 
due  dates  reduces  the  risk  of  errors  and  omissions  in  the  project. 

For  this  project,  a  general  project  plan  was  created  but  it  did  not  include  the  level 
of  detail  for  each  phase  nor  did  it  include  a  timeline  for  completion  of  individual  tasks. 
Had  this  been  done,  the  prototype  application  would  have  been  completed  earlier 
allowing  for  more  reviews  and  iterations,  resulting  in  a  better  product. 

A  detailed  project  plan  would  have  also  generated  a  checklist  of  items  to  ensure 
that  all  the  requirements  had  been  met.  This  problem  arose  when  discussing  the 
prototype  application  with  the  Community  Management  Analyst.  He  pointed  out  that  the 
Staffing  Plan  also  has  a  personnel  listing  at  the  front  of  the  plan.  This  item  had  been 
missed  initially,  requiring  additional  work  to  add  the  personnel  listing  to  the  Staffing 
Plan.  Had  a  checklist  of  required  items  been  created,  the  personnel  listing  would  have 
been  included  in  the  first  iteration  of  the  prototype. 
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B.  RECCOMENDATIONS 


1.  Support  A  Follow-On  Project  That  Will  Include  The  Following : 

a.  Integration  with  the  NPDB 

Any  future  work  on  this  system  should  focus  on  integrating  the  application 
with  the  NPDB.  The  application  should  not  be  allowed  to  modify  anything  in  the  NPDB 
without  proper  approval,  but  a  read-only  view  of  the  data  would  provide  a  more  efficient 
method  of  providing  the  information  required  by  the  CEC  detailers.  It  is  likely  that  using 
a  view  from  the  NPDB  would  negate  the  need  for  much  of  the  data  cleansing  currently 
required.  The  data  cleansing  portion  of  work  is  the  most  time  consuming  and  frustrating 
for  the  users.  Taking  this  step  out  would  improve  office  efficiency  and  productivity. 

b.  Provide  Web  Access  to  the  System 

The  P- 1  document  is  read  by  every  CEC  officer  in  every  part  of  the  world. 
The  best  tool  to  deliver  this  document  worldwide  is  the  Internet.  A  follow  on  thesis 
project  could  provide  a  web  management  tool  for  the  detailers  as  well  as  an  Internet 
version  of  the  P-1.  The  detailers  maintain  a  heavy  travel  schedule.  A  web  management 
tool  for  the  detailers  would  give  them  access  to  the  information  they  may  need  while 
traveling  to  different  regions.  A  web  version  of  the  P-1  could  have  many  enhanced 
search  capabilities  so  that  a  CEC  officer  could  search  for  a  particular  type  of  billet  where 
the  incumbent  member  is  due  to  rotate  in  a  given  period.  A  prototype  for  this  type  of 
interface  was  recently  completed  in  another  thesis  project.  Combining  that  prototype 
with  this  application  would  be  an  interesting  and  worthwhile  project  that  would  provide 
great  benefits  to  the  CEC  community. 

c.  Enhance  Functionality 

Currently,  every  time  the  users  want  to  create  the  P-1  or  Staffing  Plan, 
they  must  import  a  fresh  set  of  data  to  the  database  and  clean  it  up  all  over  again.  An 
idea  for  increased  functionality  could  be  to  import  the  fresh  data  and  compare  it  to  the 
existing  data.  Only  the  conflicting  data  would  be  shown  to  discard,  add,  or  change.  This 
may  streamline  the  data  import  process  if  done  on  a  regular  basis.  Other  functionality 
enhancements  requested  by  the  users  could  be  accomplished  as  well. 
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2. 


Reexamine  Current  Business  Processes  and  Rules 


One  of  the  issues  encountered  during  the  development  of  this  system  was  how  the 
CEC  defines  activities  differently  than  the  Navy.  In  the  existing  ODIS  system,  activities 
are  defined  by  their  UIC,  whereas  the  CEC  further  breaks  down  those  activities  into 
several  more.  This  situation  made  it  extremely  difficult  to  relate  billets  and  personnel  to 
activities.  Perhaps  the  NPDB  contains  a  unique  identifier  that  further  breaks  down  the 
activities  to  the  level  of  detail  that  the  CEC  wants  to  see,  but  I  was  not  able  to  get  a  look 
at  the  data  or  the  structure  of  the  NPDB.  Standardization  across  the  Navy  for  what 
defines  an  activity  should  be  addressed  for  future  enterprise  systems. 

Another  issue  is  how  a  billet  is  defined.  Currently  a  Public  Works  Officer  billet  at 
one  activity  is  different  from  a  Public  Works  Officer  billet  at  another  activity.  In  an  ideal 
model,  there  would  be  one  Public  Works  Officer  billet  that  could  reside  in  many 
activities.  In  other  words,  the  relationship  between  activity  and  billet  would  be  many-to- 
many  instead  of  one-to-many.  Perhaps  the  billets  are  currently  organized  due  to  financial 
reasons.  Each  billet  is  associated  with  certain  cost  information.  This  information  could 
easily  be  input  into  the  intersection  table,  making  for  a  much  cleaner  database  schema. 

C.  CONCLUSIONS 

The  original  concept  of  this  thesis  was  to  create  a  much  larger  system  that  the 
CEC  detailers  would  use  on  a  daily  basis  and  have  a  web  interface  for  the  CEC 
community  to  access.  The  web  interface  would  pull  its  information  directly  from  the 
database  residing  at  BUPERS.  The  application  would  be  used  to  manage  all  data  related 
to  CEC  officers  and  support  the  production  of  the  P-1  and  Staffing  Plan.  The  scope  of 
this  project  was  reduced  considerably  after  the  initial  discovery  trip.  The  web  site  could 
not  be  hosted  at  BUPERS,  but  would  have  to  be  hosted  at  the  Naval  Facilities 
Engineering  Command  Information  Technology  Center  (NITC)  in  Port  Hueneme,  CA. 
The  detailers  did  not  want  any  new  system  to  manage  their  information.  They  only 
wanted  an  easier  method  to  produce  the  Staffing  Plan  and  P-1.  The  scope  was  further 
reduced  to  its  current  state  when  the  other  CEC  officer  received  orders  to  leave  earlier 
than  expected. 


85 


Working  under  the  constraints  of  importing  the  data  from  the  delimited  text  files 
resulted  in  a  system  that  is  not  as  flexible  as  desired.  Any  change  to  the  delimited  files 
will  result  in  a  requirement  to  modify  the  data  import  routines.  A  view  of  the  existing 
NPDB  would  have  provided  a  more  adaptable  system  than  the  current  one. 

Although  the  system  is  not  perfect,  it  does  meet  the  goals  set  forth  in  the 
beginning  of  this  thesis.  The  system  successfully  integrates  itself  with  the  legacy  systems 
via  data  import  routines.  The  method  of  importing  and  cleansing  the  data  is  now  easier  to 
than  before.  Once  the  data  is  in  the  system,  simple  maintenance  with  user-friendly  forms 
can  be  done  allowing  for  the  rapid  generation  of  the  Staffing  Plan  and  P-1.  In  its  current 
state,  the  system  meets  the  requirements  of  the  end-users  and  serves  its  purpose  until  a 
permanent  solution  can  be  developed. 
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APPENDIX  A:  DEFINITION  OF  TERMS 


Macro 

Primary  Key 

Relationships 

Queries 

Legacy  system 

Entities 

Scalability 


Stovepipe 


End-user 


Data  integrity 


A  saved  sequence  of  commands  or  keyboard  strokes  that 
can  be  stored  and  then  recalled  with  a  single  command  or 
keyboard  stroke. 

A  unique  field  in  a  table  which  identifies  the  row. 

Defines  how  entities  interact  with  each  other 

A  question  required  to  be  expressed  in  a  specific  manner  to 
locate,  update,  add,  or  delete  records  in  a  database  table 

System  that  have  been  inherited  from  languages,  platforms, 
and  techniques  earlier  than  current  technology 

Some  unit  of  data  that  can  be  classified  and  have  stated 
relationships  to  other  entities 

The  ability  of  a  computer  application  or  product  (hardware 
or  software)  to  continue  to  function  well  as  it  (or  its 
context)  is  changed  in  size  or  volume  in  order  to  meet  a 
user  need 

A  system  that  is  in  place  to  serve  only  the  primary  user  and 
does  not  interact  or  interface  with  other  systems  in  use 

Personnel  for  whom  a  hardware  or  software  product  is 
designed 

Refers  to  the  validity/reliability  of  data 
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APPENDIX  B:  INITIAL  DISCOVERY  TRIP  REPORT 


Trip  Report 


Initial  Visit  to  Navy  Personnel  Command 
18-20  June  2001 


Presented  By: 


WtjBrifak* 

Development  Team 

P 1  Team@  nps.  navy,  mil 


Brian  Weinstein  LT,  CEC,  USN 
& 

Chris  Rader  LTJG,  CEC,  USNR 


3  July  2001 
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Executive  Summary 


The  ultimate  goal  of  our  project  is  to  make  the  PI  readily  available  online  to  the 
entire  CEC  community.  With  this  goal  in  mind  and  a  thesis  to  complete,  we  considered 
the  technological  and  design  possibilities  and  came  to  the  conclusion  that  a  Community 
Management  System  would  be  the  logical  companion  to  the  PI.  This  combination  is  also 
perfect  in  size  and  scope  for  our  thesis  work.  This  initial  trip  to  Naval  Personnel 
Command  (NAVPERSCOM),  funded  by  Naval  Postgraduate  School,  was  necessary  to 
begin  work  on  a  coherent  PI  Online  and  a  Community  Management  System.  This  report 
is  intended  to  serve  as  a  research  findings  document  provided  to  PERS  4413  as  a  result  of 
the  trip. 

The  initial  trip  to  Navy  Personnel  Command  had  several  purposes  and  was  critical 
for  establishing  a  direction  for  the  next  phase  of  the  project,  the  Design  and  Development 
Phase.  Our  initial  vision  was  to  provide  an  integrated  Community  Management  System 
that  would  tie  directly  into  the  existing  NAVPERSCOM  system  including  a  web-based 
capability  that  would  be  available  to  all  members  of  the  CEC  community  worldwide. 

The  integration  of  the  system  with  the  existing  NAVPERSCOM  system  would  have 
allowed  for  near  real-time  data  access.  Unfortunately,  technical  as  well  as  policy  related 
factors  make  the  integration  of  a  new  system  with  the  NAVPERSCOM  system  not 
feasible  within  reasonable  time  and  cost  constraints. 

The  primary  goals  of  the  trip  were  to  learn  the  fundamentals  of  the  detailing 
process,  to  evaluate  NAVPERSCOM  systems  (hardware  and  software),  and  to  refine  the 
scope  of  the  project.  A  basic  understanding  of  the  detailing  process  was  obtained  through 
question  and  answer  sessions  with  each  of  the  PERS  4413  detailers.  Each  of  the  detailers 
was  questioned  on  how  they  accomplish  their  tasks  and  what  information  systems  they 
use  to  facilitate  their  processes.  Several  thorough  discussions  were  held  with 
NAVPERSCOM  staff  members  in  coordination  with  participant  observation  of  existing 
hardware  and  software  systems  currently  in  use.  Both  hardware  and  software  systems  at 
NAVPERSCOM  are  very  outdated  as  noted  in  Paragraph  l.b.  Page  3.  The  existing 
systems  do  not  readily  lend  themselves  to  integration  with  a  new  system  and  PERS  4413 
does  not  wish  to  create  a  new  system  that  could  be  incompatible  with  existing  or  planned 
software.  With  this  in  mind,  a  revised,  limited  scope  of  work  has  been  developed  to 
communicate  the  specific  deliverables  that  will  be  provided  to  PERS  4413.  Specifically, 
the  deliverables  include  the  PI  Online,  an  improved  Access  database  to  facilitate 
management  of  the  PI  data,  and  an  advanced  reporting  capability  available  to  the 
members  of  the  CEC  detail  shop.  On  our  own,  we  will  also  continue  on  with  the  entire 
original  scope  of  the  Community  Management  System  for  the  purpose  of  our  thesis  using 
the  basic  knowledge  obtained  in  the  initial  trip.  We  plan  to  demonstrate  this  capability  to 
the  PERS  4413  staff  in  order  to  allow  an  opportunity  for  the  staff  to  request  additional 
functionality  in  the  deliverable  system  and  to  obtain  feedback  relative  to  our  thesis. 

The  trip  to  Millington  was  highly  informative  and  beneficial.  We  discovered 
basic  information  regarding  the  detailing  process  and  how  information  systems  currently 
facilitate  the  process.  Our  goal  is  to  complete  the  PI  Online  and  the  improved  Access 
database  with  additional  reporting  capabilities  for  the  Civil  Engineer  Corps  and  its 
detailers,  as  well  as,  develop  a  full  blown  conceptual  system  for  the  completion  of  our 
thesis  for  Naval  Postgraduate  School. 
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Introduction 


Our  initial  trip  to  Navy  Personnel  Command  (NAVPERSCOM)  Code  4413  was 
challenging,  but  successful.  Our  goal  was  to  develop  a  basic  understanding  pertaining  to 
Navy  Personnel  Command  operations  and  information  systems.  Specifically,  we  focused 
our  efforts  on  the  following  areas: 

1.  Achieve  a  basic  understanding  of  the  detailing  process. 

2.  Understand  PI /Staffing  Plan  generation 

3.  Understand  the  purpose  of  the  Staffing  Plan 

4.  Evaluation  of  current  NAVPERSCOM  systems  and  databases  in  use 

5.  Investigate  current  architecture/infrastructure  of  IT  systems  at 
NAVPERSCOM 

6.  Discuss  fiscal  issues 

We  were  successful  in  accomplishing  our  goals  for  the  initial  trip.  We  were  able  to 
obtain  a  substantial  amount  of  information  from  the  NAVPERSCOM  staff.  The 
following  section  describes  the  trip’s  results. 

Discoveries 


1.  Existing  Systems 

a.  Standard  Navy  Personnel  Management  Systems 

Based  on  the  initial  visit,  our  understanding  of  the  current  system  architecture 
is  displayed  in  Figure  1. 
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Figure  1:  Current  System  Architecture 


The  master  file  for  the  Navy  (OPINS)  is  maintained  on  a  large  mainframe 
located  in  Cleveland,  OH.  The  locally  maintained  mainframe  (OAIS)  handles  the 
day-to-day  operations  for  personnel  management.  The  personnel  in  the  detail 
shop  make  any  changes  with  regards  to  personnel  or  billets  in  this  system.  OAIS 
and  OPINS  perform  nightly  transaction  updates  to  synchronize  the  information. 
When  a  staff  member  needs  to  extract  information  to  create  reports  or 
spreadsheets  to  perform  their  duties,  this  data  is  taken  from  the  Officer 
Distribution  Information  System  (ODIS)  in  ASCII  format.  The  ASCII  data  is 
downloaded  in  a  delimited  format  and  imported  into  Microsoft  Excel  for 
manipulation  and  reporting.  The  Electronic  Military  Personnel  Record  System 
(EMPRS)  is  a  separate  application  that  the  detailers  use  to  view  their  constituents’ 
digital  records  during  the  detailing  process.  The  four  systems  represented  here 
are  all  stovepipe  mainframe  applications  that  do  not  relate  to  each  other  except  in 
a  nightly  transaction- oriented  process  for  synchronization  of  data. 

b.  PERS  4413  Systems 

Evaluation  of  NAVPERSCOM  systems,  databases,  and  spreadsheets  currently 
in  use  was  one  of  the  objectives  of  the  visit.  The  current  platforms  used  are 
the  following: 
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Hardware:  Pentium  desktop  systems  that  are  approximately  4  years  old. 
The  average  processor  speed  is  around  166  MHz,  with  each  containing  64 
MB  of  RAM. 


Software:  All  of  the  personnel  are  running  on  Microsoft  Windows  95 
Operating  System  with  Microsoft  Office  97  for  their  Office  Application 
Suite. 

Windows  95  is  still  being  used  because  the  EMPRS  system  was  coded 
specifically  for  Windows  95  and  the  contractor  went  out  of  business  and  took 
the  source  code  with  them,  therefore  no  changes  have  been  made.  There  are 
current  efforts  underway  at  NAVPERSCOM  to  rewrite  the  EMPRS  system  so 
it  can  be  used  with  the  latest  operating  systems.  The  Navy  Marine  Corps 
Intranet  (NMCI)  is  another  reason  for  a  delay  in  the  upgrade  of  systems  and 
software  at  NAVPERSCOM.  The  command  intends  to  upgrade  the  systems 
during  the  rollout  of  NMCI,  which  has  been  delayed  until  next  year  with  no 
specific  timeframe  for  execution. 

2.  NAVPERSCOM  Support 

NAVPERSCOM  is  currently  undertaking  many  IT  related  projects  including,  but 
not  limited  to,  NMCI,  legacy  systems  upgrades,  and  an  upgrade  to  the  EMPRS 
system.  There  is  a  local  development  project  underway  (SEERS)  which  is  supposed 
to  combine  all  the  stovepipe  systems  into  one  relational  model  for  use  by 
NAVPERSCOM.  The  systems  described  above  are  all  planned  to  be  included  in  this 
local  project  along  with  other  systems  not  mentioned.  There  is  currently  no 
timeframe  for  the  execution  of  this  project  and  it  is  understood  to  be  just  in  the 
conceptual  phase,  which  leads  to  the  estimation  that  the  successful  completion  of  this 
project  is  at  least  5  years  away.  There  is  also  a  project  underway  at  NAVPERSCOM 
to  try  and  make  these  management  systems  entirely  web  based.  DOD  is  also 
examining  the  possibility  of  developing  the  Defense  Integrated  Human  Resource 
System  (DIMRS),  which  is  intended  to  be  a  personnel  management  application  for 
the  entire  military.  It  is  not  known  whether  these  two  projects  will  be  integrated, 
superceded,  or  separated.  Given  the  number  and  magnitude  of  the  projects  that 
NAVPERSCOM  is  undertaking,  they  expressed  great  concern  in  allowing  another 
system  to  be  created  to  support  PERS  4413  outside  the  realm  of  their  oversight.  This 
issue  alone  led  us  to  modify  our  original  scope  as  will  be  discussed  later  in  this 
document. 

3.  Data  Discrepancies  and  Integration 

Inherent  with  static  display  applications  come  certain  data  discrepancies.  These 
are  created  by  the  lag  time  between  updates  of  each  stovepipe  system.  A  transaction 
oriented  update  system  can  also  lend  itself  to  the  possibility  of  errors  and  omissions. 
An  update  may  be  sent  to  one  system  with  no  error  checking  to  see  if  the  other  system 
received  all  the  information  correctly.  There  may  also  be  old  information  in  the 
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system  that  has  not  been  removed  or  updated.  Given  these  possibilities,  there  must  be 
a  data  validation  method.  This  validation,  or  sanity  check,  must  be  performed  each 
time  data  is  extracted  from  ODIS  and  imported  into  MS  Excel.  This  type  of 
validation  requires  a  considerable  amount  of  corporate  knowledge  only  known  by  the 
staff.  In  terms  of  preparation  of  the  PI  and  the  Staffing  Plan,  PERS  4413s  (Dennis 
Potter)  spends  approximately  8  hours  every  two  to  three  months  performing  the  data 
manipulation  and  validation  to  produce  each  instance  of  the  PI  and  Staffing  Plan. 

After  discovering  what  current  systems  were  being  used  and  how  they  related,  we 
determined  that  actual  real-time  integration  of  the  existing  systems  with  the  PI 
database  was  not  possible.  This  is  due  to  the  architecture  of  the  systems  and  also  the 
policies  and  projects  underway  by  NAVPERSCOM.  The  current  systems  are 
mainframe  applications  that  maintain  separate  flat  files  with  the  data.  This  type  of 
architecture  does  not  lend  itself  to  an  integrated  relational  model,  which  is  generally 
the  most  efficient  for  data  handling. 

4.  Work  Processes 

During  the  trip,  time  was  spent  with  each  member  of  the  PERS  4413  team 
investigating  how  they  do  business  and  what  tools  they  use  to  accomplish  their  day- 
to-day  tasks.  We  discovered  that  while  the  methodologies  that  each  detailer  uses  to 
perform  their  tasks  are  generally  different;  the  data  that  is  required  to  support  them  is 
quite  similar.  The  main  differences  in  how  they  use  the  data  is  in  the  sorting,  display, 
and  a  few  different  field  selections.  Each  detailer  uses  a  spreadsheet  that  originates 
from  an  ODIS  data  pull.  All  of  the  spreadsheets  are  very  similar,  but  have  minor 
differences  in  implementation.  Each  detailer  also  uses  Microsoft  Outlook  for  a 
journal  of  detailing  activity.  This  journal  capability  provides  a  link  between  e-mails 
and  notes  made  by  the  detailer.  Each  detailer  keeps  a  handwritten  phone  log,  varying 
from  a  record  of  date,  time,  and  conversation  to  just  a  message  of  who  called  with  a 
note  to  call  them  back.  All  the  detailers  use  e-  mail  and  the  telephone  extensively  to 
communicate  with  their  constituents. 

5.  Staffing  Plan  &  PI  Generation 

As  mentioned  earlier,  the  process  by  which  the  Staffing  Plan  and  PI  are  generated 
is  lengthy  and  arduous.  It  generally  takes  a  minimum  of  one  full  day  of  Mr.  Potter’s 
time  every  time  the  Staffing  Plan  or  the  PI  is  generated.  During  the  trip,  we 
witnessed  the  generation  of  the  Staffing  Plan.  The  process  starts  with  two  separate 
ASCII  formatted  data  pulls  from  ODIS.  One  pull  is  data  on  bodies  (personnel)  and 
the  other  is  data  on  billets.  Once  these  ASCII  files  are  pulled,  they  are  imported  into 
MS  Excel  and  then  manually  manipulated  for  data  validation  and  cleanup.  This 
manual  manipulation  and  validation  takes  approximately  four  hours  for  completion. 

It  appears  that  much  of  this  manipulation  and  validation  can  be  automated,  but  there 
is  still  some  that  must  be  checked  manually.  For  example,  the  data  pull  brings  in 
many  reserve  CEC  officers  who  are  not  included  in  the  Staffing  Plan  or  PI. 

Currently,  the  only  way  to  know  whether  or  not  to  include  them  is  by  corporate 
knowledge  of  the  CEC  community.  Once  all  the  manipulation  is  completed  in  MS 
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Excel,  the  data  is  then  imported  into  an  existing  MS  Access  Database  where  internal 
queries  and  macros  in  the  database  attach  the  billets  to  bodies  and  then  perform  some 
further  validation  and  manipulation.  The  manual  manipulation  in  MS  Access  also 
takes  approximately  four  hours.  After  this  process  was  completed,  the  Staffing  Plan 
was  finished.  The  existing  MS  Access  Database  is  essentially  a  collection  of 
spreadsheets  that  do  not  have  primary  keys  or  relations  to  each  other.  Therefore,  the 
Access  database  is  not  a  relational  database  rather  a  reporting  tool.  The  existing 
queries  appear  to  create  the  relationships  as  needed.  There  is  duplication  of  data  in 
these  tables  that  can  be  solved  by  creating  a  relational  model,  which  will  make  the 
process  of  generating  the  Staffing  Plan  and  PI  simpler  and  much  more  efficient. 

Once  the  PI  is  generated  in  the  Access  database,  it  is  shipped  via  email  to  Mr.  John 
Wang  at  NITC  in  Port  Hueneme,  CA.  Mr.  Wang  then  takes  the  database  and  places  it 
on  a  server  for  the  NAVFAC  intranet  web  pages  to  access.  This  process  is  done  once 
or  twice  a  year.  Theoretically,  if  the  PI  database  is  kept  current  through  a  more 
efficient  means,  a  web  site  hosted  at  NAVPERSCOM  that  pointed  to  the  updated 
database  would  be  more  current  then  the  one  which  is  shipped  to  NITC  once  or  twice 
a  year.  Because  the  PI  is  a  community  management  tool  and  not  an  officially 
supported  document  and  given  the  current  projects  underway  at  Navy  Personnel 
Command,  they  did  not  express  any  interest  or  desire  to  host  the  PI  website.  For  this 
reason,  it  was  determined  to  continue  to  work  with  NTIC  for  the  online  publication  of 
the  PI. 

Revised  Scope 

After  an  initial  visit  to  Navy  Personnel  Command  Code  4413  and  at  the  request  of 
PERS  4413,  it  has  been  determined  that  the  deliverable  scope  of  work  will  be  reduced. 
The  detail  shop  did  not  request  the  original  scope  of  work,  which  included  the 
Community  Management  System,  nor  do  they  plan  on  implementing  our  complete 
product.  For  the  purposes  of  fulfilling  the  thesis  requirements  and  our  continuing 
education  at  the  Naval  Postgraduate  School,  we  will  continue  to  develop  the  Community 
Management  System  based  on  the  knowledge  we  have  gained  thus  far  at  no  additional 
cost.  If,  during  the  course  of  development,  PERS  4413  requests  additional  functionality 
that  is  included  in  our  thesis  work  it  will  be  possible  to  incorporate  those  changes  into  the 
specific  deliverables.  The  following  sections  describe  how  the  project  will  be  broken  up 
into  deliverables  and  thesis  work. 

1.  Deliverables 

The  NAVPERSCOM  deliverable  will  have  its  own  scope  of  work  that  will  be 
a  small  subset  of  the  entire  scope  of  work.  It  will  include  an  Access  database 
built  to  incorporate  all  the  information  utilized  in  the  PI  and  the  staffing  plan. 

This  deliverable’s  criteria  are  that  it  must  allow  for  fast  transactions  and  be  user 
friendly  and  easily  maintained.  It  will  be  designed  in  a  relational  manner,  and  it 
will  provide  fast  search,  sort,  and  reporting  capabilities  to  the  PERS  4413  staff. 
Mr.  Potter,  as  part  of  his  day-to-day  business,  will  maintain  this  database.  We 
will  provide  him  with  a  users  guide.  The  database  will  be  very  user  friendly  and 
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will  require  minimal  work  to  validate  against  the  ODIS  data  pulls  with  which  it 
must  be  coordinated.  The  goal  of  the  project  is  to  allow  for  this  task  to  be 
performed  on  a  daily  basis.  When  this  goal  is  met,  it  will  greatly  facilitate  the 
database’s  reporting  capability,  and  it  will  also  provide  the  backbone  for  a  very 
current  PI  Online  database.  The  deliverable  scope  will  also  include  the  PI  Online 
personnel  directory.  This  PI  Online  will  be  similar  in  purpose  to  the  current 
directory  that  is  available  on  the  NAVFAC  intranet.  The  new  website  will  have 
expanded  search  capabilities  to  include  easy  to  use  methods  of  searching  for 
members  of  the  CEC,  billets,  activities,  and  combinations  of  the  above.  The  new 
site  will  be  designed  in  keeping  with  the  style  of  the  current  PI  and  will  utilize 
Active  Server  Page  technology  to  access  the  PI  database.  The  website  will  also 
provide,  to  the  extent  the  community  desires  and  regulations  allow,  an  integration 
of  personal  contact  information.  The  website  will  be  secured  using  modern  web- 
security  technologies  in  order  to  make  sure  that  the  information  is  available  only 
to  authorized  users  of  the  system.  The  Civil  Engineer  Corps  is  pushing  towards 
more  web  based  applications  and  the  PI  Online  is  just  another  piece  of  this 
picture. 

2.  Thesis  Work 

The  entire  scope  of  work  for  this  project  is  larger  than  described  above.  For 
the  purpose  of  thesis  research,  an  entire  Community  Management  System  will  be 
developed.  This  system  will  combine  a  desktop  system  with  an  online  capability. 
The  desktop  system  will  provide  detailers  an  integrated  system  for  managing 
billets,  bodies,  and  assignments.  It  will  provide  a  detailing  journal,  detailing 
preference  viewing,  contact  information,  assignment  history  and  summary,  and 
other  features  as  developed.  This  system  will  be  integrated  with  an  expanded 
version  of  the  online  personnel  directory  that  will  include  contact  information 
updates,  detailing  preference  submissions,  as  well  as  a  search  capability  for 
people,  jobs,  and  activities  real  time  from  the  active  Community  Management 
System  database.  The  entire  system  will  be  built  with  the  intention  of  being  a 
stand-alone  system  capable  of  supporting  a  detailing  office  for  a  community 
similar  in  size  to  the  Civil  Engineer  Corps.  The  system  will  not  be  designed  with 
the  intention  of  implementation  because  some  of  the  capability  is  already 
provided  by  the  OAIS  system  used  by  Navy  Personnel  Command  and  any  newly 
created  systems  will  not  be  supported.  We  would  like  the  opportunity  to 
demonstrate  the  capability  of  the  system  to  the  PERS  4413  staff  in  order  to  obtain 
feedback  relative  to  the  completion  of  our  thesis.  This  will  also  give  the  detailers 
an  opportunity  to  evaluate  the  capabilities  of  the  Community  Management  System 
and  consider  incorporation  of  some  of  its  advanced  features  into  the  above 
NAVPERSCOM  deliverables. 
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Revised  Cost  Proposal 


As  with  any  project,  cost  is  a  factor.  This  project’s  primary  expense  includes 
reference  materials,  limited  software  licenses,  and  travel  cost  to  NAVPERSCOM  and 
NITC.  The  initial  cost  proposal  submitted  included  costs  for  additional  hardware  and 
software  purchases  necessary  for  the  implementation  of  the  originally  envisioned  system 
hosted  at  NAVPERSCOM.  The  revised  cost  proposal  submitted  following  the  trip 
removed  the  additional  hardware  and  software  costs  but  also  included  additional  costs  for 
travel  to  NITC  to  discuss  and  implement  the  web  solution  there.  Based  on  discoveries 
from  the  trip  and  further  discussions  with  PERS  4413  since  returning,  the  scope  has  been 
revised  as  previously  mentioned.  With  this  revised  scope  comes  an  additional  revision  in 
the  cost  proposal.  The  revised  proposal  is  provided  below. 


Phase  I  -  Feasibility  Study  &  Business  Model  Analysis 

FY  Estimate 

Notes 

1.  Initial  scope  of  work 

Funded  by 

2.  Fact  finding  trip  to  NAVPERSCOM 

a.  Business  model  analysis 

b.  Hardware  evaluation 

c.  Software  evaluation 

d.  Network  evaluation 

NPS 

4.  Fact  finding  trip  to  NITC  Port  Hueneme 

POV  travel  down  to  Port  Hueneme  ( 1 

(John  Wang) 

5.  Refine  scope  of  work 

6.  Cost  Benefit  Analysis 

7.  Identification  of  data  migration  issues 

8.  Data  Modeling 

01  $500 

night  stay) 

Phase  I  Subtotal 

$500 

Phase  II  -  Design  &  Development 

FY  Estimate 

Notes 

1.  Resolution  of  data  migration  issues 

2.  Microsoft  Access  database  development  01  $205  Reference  Books 

a.  GUI  interface 
conceptual  design 

b .  GUI  interface 

development 


c.  Prototyping  &  Testing 

3.  Web  interface  development  01  $310  Reference  Books 

a.  Web  site  conceptual 

diagram 


b.  Website  development 

c.  Prototyping  &  Testing 

4.  Report  development  01  $430  Crystal  Reports  8.5 

a.  Report  layout  drafting 

b.  Report  development 

97 


c.  Prototyping  &  testing 


5.  Complete  data  migration 

6.  Software  purchase  (required) 01 $320  Office  2000  or  XP  for  Dennis  Potter 


Phase  II  Subtotal 

Phase  III  -  Beta  Testing 

$1,265 

FY  Estimate 

Notes 

1.  Beta  testing  trip  to  NAVPERSCOM 

2.  Beta  revision  discussions 

3.  Beta  revisions  per  previous  discussions 

02  $2,000 

Phase  III  Subtotal 

$2,000 

Phase  IV  -  Implementation  &  Training 

FY  Estimate 

Notes 

1.  Help  file  development 

2.  Final  application  &  web  interface 
changes 

3.  Final  data  migration  and  validation 

4.  Implementation  trip  to  NITC,  Port 

02  $300 

Software  and  Books 

Hueneme 

5.  Implementation  &  training  trip  to 

02  $1,500 

NAVPERSCOM 

02  $2,500 

Phase  IV  Subtotal 

$4,300 

Cost  Summary 

Estimate 

Notes 

Fiscal  Year  2001  Total 

$1,765 

Fiscal  Year  2002  Total 

$6,300 

Grand  Total 

$8,065 

Please  note  that  additional  trip  funding  may  be  necessary  if  additional  functionality  is 
requested  during  the  Beta  Testing  Phase  of  the  project. 

It  is  also  recommended  that  the  systems  (hardware  and  software)  in  PERS  4413  be 
upgraded  at  the  earliest  opportunity.  At  a  minimum,  Dennis  Potter  will  require  an 
upgrade  to  Microsoft  Office  2000  Professional  or  XP  Professional.  This  cost  is  included 
in  the  above  proposal. 

Closing  Remarks 

We  would  like  to  take  this  opportunity  to  thank  the  staff  of  PERS  4413  for  their 
support  during  our  initial  visit  to  NAVPERSCOM.  We  recognize  that  the  trip  came 
about  with  very  short  notice,  and  we  appreciate  the  detailer’s  willingness  to  be  flexible  in 
allowing  us  time  to  meet  with  them.  We  look  forward  to  providing  PERS  4413  and  the 
Civil  Engineer  Corps  a  quality  product.  Your  continued  support  is  critical  to  the  success 
of  this  goal.  Thanks  again,  and  please  feel  free  to  contact  us  with  any  comments  or 
questions.  The  team  can  be  reached  at  PlTeam@nps.navy.mil. 
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APPENDIX  C:  SPREADSHEET  TOOLS  USED  BY  DETAILERS 


SPREADSHEETS  ARE  REPRESENTATIVE  OF  FORMAT,  BUT  CONTAIN  NO  VALID  DATA 


P4413A  DETAILING  MANAGEMENT  SPREADSHEET 

BSC 

COMMAND 

TITLE 

BILLET 

RANK 

I- 

RANK 

PROM 

INCUMBENT 

YG 

RPTD 

PRD 

ULT 

BILLET 

PRIMARY 

IDEA 

IDEA 

COMMENTS 

05784 

ACB  2 

Cmpny 

Off 

LCDR 

LCDR 

zl 

Name 

90 

9909 

0109 

PG  Schl 

Name  1 

Name 

2 

Name 

3 

P4413E  DETAILING  MANAGEMENT  SPREADSHEET 

RANK 

NAME 

YG 

PROM 

PREC# 

DOR 

DUTY 

STATION 

RPTD 

PRD 

APPROVED 

PREF  1 

PREF  2 

PREF 

3 

PREF 

4 

COMMENTS 

LT 

NAME 

1990 

SO 

9843098 

19940201 

NSCHCECOFF 

PHUNE 

20000201 

200202 

P4413C  DETAILING  MANAGEMENT  SPREADSHEET 

B- 

RANK 

B-DESIG 

ACTVY 

B- 

TITLE 

YG 

RANK 

PROM 

NAME 

PRD 

ULT 

ACTVY 

BACK 

FILL 

AUIC 

BSC 

TYPE 

LOCN 

LTJG 

5100 

NMCB 

FIVE 

CMPY 

OFF 

2002 

ENS 

NAME 

200202 

DLI 

NAME 

93439 

82538 
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APPENDIX  D:  SAMPLE  ASCII  DELIMITED  FILES 


DATA  PRESENTED  BELOW  ARE  REPRESENTATIVE  OF  FORMAT,  BUT  CONTAIN  NO  VALID  DATA 

4530907500100021  !40140!LCDR!AIDE/N4A1  AIDE/ ADMIN  ASSISTANCE!ACD!!!!OPNAV!5100!000000!999999!11!02110100!ARLING 
4530907500100021 141415 1LCDR1LOGISTICS/NN22D  CARGO  OFFLOAD  SYS1ACD11110PNAV15100100000019999991111021101001ARLING 

SAMPLE  FROM  THE  BILLETS  FILE 


12345 198765 1LT1WEINSTEIN  BRIAN  LOUIS  119940 15 100 112000 1226  !*!LNFEC  NORVA1000000001!  U1155 114 105290 1MCB  5151001FAC  ENG/ASST 
CONTINGENCY  ENGR1LT1200207 15 1001LT1CMPNY  OFF  NCF1200407 1 1 1 1 1 1025 1 1760!  1Y1C !M!  123456789!  100!  1 1 1 1 


SAMPLE  FROM  THE  BODIES  FILE 
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APPENDIX  E:  SAMPLE  SPREADSHEETS  OF  IMPORTED  DATA 


DATA  PRESENTED  BELOW  ARE  REPRESENTATIVE  OF  FORMAT,  BUT  CONTAIN  NO  VALID  DATA 


IMPORTED  BILLET  INLORMATION 


MIC 

BSC 

BRANK 

BTITLE 

PAQD  SAQD  BSSC  ADDU 

SNAME 

BDESIG 

BEGIN 

END 

MMC 

COMMENTS 

GEOLOC 

mil 

00101 

LCDR 

AIDE 

ACD 

OPNAV 

5100 

000000 

999999 

11 

02110100 

ARLING 

11111 

00110 

LCDR 

LOGISTICS 

ACD 

OPNAV 

5100 

000000 

999999 

11 

02110100 

ARLING 

IMPORTED  BODIES  INFORMATION 


A  LIC 

BSC 

RANK 

NAME 

YRGRP  DESIG  SSC 

RECDDT 

PRD 

ACTNAME 

PRECNBR 

12345 

99990 

LT 

WEINSTEIN  BRIAN  LOUIS  19940  5100  6201T 

20000813 

200209 

S  PG  MONTEREY 

082354658 

CONTINUATION  OF  MEMBER’S  DATA 

AQD1 

AQD2 

AQD3 

AQD4 

AQD5  ULTAUIC  ULTBSC 

ULTSNAME 

BDESIG 

BTITLE 

BRANK 

950 

AC1 

* 

CONTINUATION  OF  MEMBER’S  DATA 

ULTEDA 

ULTBDESIG 

ULTBRANK 

ULTBTITLE 

ULTPRD  AQD6  AQD7 

AQD8 

AQD9 

AQD10 

GEOLOC 

02062250 


CONTINUATION  OF  MEMBER’S  DATA 


PROMSTAT 

ETHNIC 

RACE 

SEX 

SSN 

X 

C 

M 

123456789 
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APPENDIX  F:  ORIGINAL  P-1  PROGRAM  DATA  MODIFICATION 

RULES 


RULES  FOR  MODIFYING  BIFFET  INFORMATION  FROM  THE  IMPORTED  DATA 


PI  BILLETS 

Make  majority  of  changes  in  EXCEL 

-  Add  Headers  (Titles) 

-  sort  on  PAQD  (Realign/Fix  top  records) 

-  sort  on  ADDU 

-  delete  "N"  except  (entire  record) 

UIC  BSC 

00011  47100  (OPNAVN46) 
47240 

57034  00110  (22  NCR) 

57046  05020  (30  NCR) 

62980  44580  (DETAIFERS) 
62980  44580 
62980  40245 
62980  40270 

-  sort  on  AUIC 

-  delete  the  following  records 
N1  Students  (UIC  31013) 

TPPN  (UIC  33119) 

PEP  Billets  (not  in  use) 

N4  Students  (UIC  44952) 

N7  Students 

Delete  PEP  billets  not  is  use 
41591/20445  PEP-USAF  NELLIS 
42048/34100  PEP-USAF  RAMSTEIN 
49429/001 10  PEP-USA  PANAMA 
42051/36100  PEP-USAF  OFFUTT 
42049/36100  PEP-USAF  TYNDALL 
57034/00560  (ARMY  CAPT)  2NCB 
57046/05920  (ARMY  CAPT)  3NCB 
Delete  USNR  billets 
46650/06061  HQ  NAVFAC 
00025/42495  HQ  NAVFAC 
57034/00135  ADMIN/NAVRES  2NCB 
57092/00560  NAVCOASTWARGRP1 
62638/00560  NAVCOASTWARGRP2 
63139/13010  NAVRES  S  CLARA 
32791/42550  OPNAV 


Delete  CEC  ADDU  billets 
44221/05000  EFD  SOUTH  (NPC) 
44221/05100  EFD  SOUTH  (NPC) 
44221/05200  EFD  SOUTH  (NPC) 
62477/01450  EFA  CHES  (OPNAV) 
62477/01400  EFA  CHES  (OPNAV) 
62477/05210  EFA  CHES  (BUPERS) 
Delete  NCR  billets 
55614/00110  CAPT  22NCR 
55611/00100  CAPT  31NCR 
Rename/Change 
62980/40270  to  62980/44670 
62477/00800  to  47689/00800  (WHMO) 
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PIPeople 

Make  majority  of  changes  in  EXCEL 

-  Add  Headers  (Titles) 

-  sort  on  BRANK  (Realign/Fix  top  records) 

-  sort  on  ULTTITLE  (Realign/Fix  top  records) 

-  sort  on  Rank/Desig 

-  delete  applicable  USNRs 
(04  and  above) 

-  delete  applicable  other  desigs 

-  replace  RDMU/RDML  with  RADM 

-  cut  and  paste  AQD  6-10 

-  sort  on  AQD6 

-  ensure  following  AQDs  are  in  the 


first  5 

AQD  fields: 

950 

EIT 

951 

PE 

952 

RA 

960 

sew 

APM 

Aquisition  Professional 

JS7 

JPME  Phase  I 

JS8 

JPME  Phase  II 

(above  step  for  AQD7  thru  AQD  10) 

-  delete  AQD6  through  AQD  10 
Replace  and  update  ADDU  relationship 

44221/05005  with  62980/44585 
44221/05100  with  62980/44670  (BSC  40270) 
44221/05200  with  62980/44580 
62477/01450  with  00011/47100  (CDR) 
62477/01400  with  00011/47240  (LCDR) 
62477/00800  with  47689/00800  (WHMO) 
62477/05210  with  62980/44570  (BUPERS) 
55614/00110  with  57034/00110  (2NCB) 
55611/00100  with  57046/00100  (3NCB) 

-  sort  on  ULTEDA 

-  Check  each  record  prior  to  current  month 

-  correct  any  NO  ORDERS  files 

-  add  STUDENT  to  all  "S"  B TITLES 

-  correct  any  OVERALLOWANCES 

-  correct  any  PNDING  NAVY  GAINS 

-  delete  any  Non- Accession  personnel 

-  forward  an  email  to  Carlito  Paguio  to 
have  them  deleted  from  OAIS/OPINS 
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APPENDIX  G:  DATABASE  SCHEMA 


Table:  ACTIVITY 


Properties 

DateCreated: 

9/1/2002  7:58:13  PM 

DefauItView: 

Datasheet 

Filter: 

((ACTIVITY.  UIC="45967")) 

GUID: 

{guid  {B36FF00D-85D5- 
4EF4-85E9-0018889A76B6}} 

LastUpdated: 

9/20/2002  2:01:08  AM 

NameMap: 

Long  binary  data 

OrderBy: 

ACTIVITY.  UIC 

OrderByOn: 

True 

Orientation: 

Updatable: 

Left-to- Right 

True 

RecordCount: 

496 

Columns 


Name 
Activityl  D 


Type 

Long  I  nteger 


Size 


UIC 


CSC 


AllowZeroLength: 

False 

Attributes: 

Fixed  Size,  Auto- Increment 

CollatingOrder: 

General 

ColumnFlidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

Primary  Key 

GUID: 

{guid  {2C3D24C3-2EB8-424B-I 

OrdinalPosition: 

0 

Required: 

True 

SourceField: 

Activityl  D 

SourceTable: 

ACTIVITY 

Text 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

CollatingOrder: 

General 

ColumnFlidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

Unit  Identification  Code 

DisplayControl: 

T ext  Box 

GUID: 

{guid  {5FBEC277-C902-4BD4-I 

IMEMode: 

0 

IMESentenceMode: 

3 

OrdinalPosition: 

1 

Required: 

False 

SourceField: 

UIC 

SourceTable: 

ACTIVITY 

UnicodeCompression: 

False 

Text 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

CollatingOrder: 

General 

ColumnFlidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

Command  Sequence  Code 

DisplayControl: 

Text  Box 
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10 


10 


GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 

Region 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnHidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 

Name 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnFlidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 

DisplayOrder 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnFlidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

DecimalPlaces: 

Description: 

DisplayControl: 

GUI  D: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

TenDigitCode 

AllowZeroLength: 


{guid  {1F88D4D2-A2EA-4A90-BA37-4B71B8EC8BB6}} 
0 
3 
2 

False 

CSC 

ACTIVITY 

False 


Text  50 

True 

Variable  Length 

General 

False 

Default 

Default 

False 

Geographical  Region 
T ext  Box 

{guid  {766E2509-5167-4545-9D02-FE66CCE44251}} 

0 

3 

3 

False 

Region 

ACTIVITY 

False 


Text  75 

True 

Variable  Length 

General 

False 

Default 

5730 

False 

Activity  Name 
T ext  Box 

{guid  {EA84F12B-C80A-4886-842F-CC8B3BA685C8}} 

0 

3 

4 

False 

Name 

ACTIVITY 

False 


Long  Integer  4 

False 

Fixed  Size 

General 

False 

Default 

Default 

False 

Auto 

Activity  Sorting  Order 
Text  Box 

{guid  {D98D96FD-2D16-4555-AB4D-86083D7A2C5C}} 

5 

False 

DisplayOrder 

ACTIVITY 


True 


Text 


10 
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Attributes: 

CollatingOrder: 

ColumnHidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 

Category 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnHidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 

Claimancy 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnHidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 

Streetl 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnHidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

GUI  D: 


Variable  Length 

General 

False 

Default 

Default 

False 

Ten  Digit  Code  for  Activity 
Text  Box 

{guid  {EEAD35D3-2458-453A-A759-9D8B94D8D875}} 
0 
3 
6 

False 

TenDigitCode 

ACTIVITY 

False 


Text  100 

True 

Variable  Length 

General 

False 

Default 

Default 

False 

Type  of  Activity 
T ext  Box 

{guid  {5CF638C9-1319-47A3-A8B1-2A01CC51CABD}} 

0 

3 

7 

False 

Category 

ACTIVITY 

False 


Text  2 

True 

Variable  Length 

General 

False 

Default 

Default 

False 

Major  Claimant  Code 
T ext  Box 

{guid  {BC5F5B83-1AE5-4E6E-9A4D-64BD3E20624F}} 

0 

3 

8 

False 

Claimancy 

ACTIVITY 

False 


Text  75 

True 

Variable  Length 

General 

False 

Default 

Default 

False 

Street  Address  1 
T ext  Box 

{guid  {C936471B-0A94-4AB4-A218-DC9B48CFBCED}} 
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IMEMode: 

0 

IMESentenceMode: 

3 

OrdinalPosition: 

9 

Required: 

False 

SourceField : 

Streetl 

SourceTable: 

ACTIVITY 

UnicodeCompression: 

False 

Street2 

Text 

75 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

CollatingOrder: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

Street  Address  2 

DisplayControl: 

Text  Box 

GUI  D: 

{guid  {353E4507-82A5-4B6C-8C79-DA9FEB4466D9}} 

IMEMode: 

0 

IMESentenceMode: 

3 

OrdinalPosition: 

10 

Required: 

False 

SourceField: 

Street2 

SourceTable: 

ACTIVITY 

UnicodeCompression: 

False 

Street3 

Text 

75 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

CollatingOrder: 

General 

ColumnFlidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

Street  Address  3 

DisplayControl: 

T ext  Box 

GUI  D: 

{guid  {54C01F8C-F07C-48F3-9109-4568AA9F2BA1}} 

IMEMode: 

0 

IMESentenceMode: 

3 

OrdinalPosition: 

11 

Required: 

False 

SourceField: 

Street3 

SourceTable: 

ACTIVITY 

UnicodeCompression: 

False 

Street4 

Text 

75 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

CollatingOrder: 

General 

ColumnFlidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

Street  Address  4 

DisplayControl: 

Text  Box 

GUI  D: 

{guid  {387E34D5-50FD-4CEE-B7B5-ADBF8E46D291}} 

IMEMode: 

0 

IMESentenceMode: 

3 

OrdinalPosition: 

12 

Required: 

False 

SourceField: 

Street4 

SourceTable: 

ACTIVITY 

UnicodeCompression: 

False 

City 

Text 

25 

110 

State 


Zip 


AllowZeroLength: 

True 

Attributes: 

Variable  Length 

CollatingOrder: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Datallpdatable: 

False 

Description: 

City 

DisplayControl: 

Text  Box 

GUI  D: 

{guid  {9BD13FC3-! 

IMEMode: 

0 

IMESentenceMode: 

3 

OrdinalPosition: 

13 

Required: 

False 

SourceField: 

City 

SourceTable: 

ACTIVITY 

UnicodeCompression: 

False 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

CollatingOrder: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

State 

DisplayControl: 

T ext  Box 

GUI  D: 

{guid  {3C555BBC-! 

IMEMode: 

0 

IMESentenceMode: 

3 

OrdinalPosition: 

14 

Required: 

False 

SourceField: 

State 

SourceTable: 

ACTIVITY 

UnicodeCompression: 

False 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

CollatingOrder: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

Zip 

DisplayControl: 

T ext  Box 

GUI  D: 

{guid  {8DEEDBA4- 

IMEMode: 

0 

IMESentenceMode: 

3 

OrdinalPosition: 

15 

Required: 

False 

SourceField: 

Zip 

SourceTable: 

ACTIVITY 

UnicodeCompression: 

False 

ur 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

CollatingOrder: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

Zip  +  4 

DisplayControl: 

T ext  Box 

Text 


Text 


Text 


2 


5 


4 
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GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 


{guid  {A6861A71-DF8B-487C-BA07-223907E40C99}} 
0 
3 

16 

False 

ZipPlusFour 

ACTIVITY 

False 


PhoneCommercial 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnFlidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

GUID: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 


Text 

True 

Variable  Length 

General 

False 

Default 

Default 

False 

Commercial  Phone  Number 
T ext  Box 

{guid  {40524B4C-93F5-4034-B578-B20B5D2DFD99}} 
0 
3 

17 

False 

PhoneCommercial 

ACTIVITY 

False 


40 


PhoneDSN 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnFlidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

GUID: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 


Text 

True 

Variable  Length 

General 

False 

Default 

Default 

False 

DSN  Phone  Number 
T ext  Box 

{guid  {140BCCEF-661A-4A4B-A37F-6F177B700E32}} 
0 
3 

18 

False 

PhoneDSN 

ACTIVITY 

False 


PhoneFax 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnFlidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

GUID: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 


Text 

True 

Variable  Length 

General 

False 

Default 

Default 

False 

Fax  Number 
T ext  Box 

{guid  {9219A197-7812-4B10-8BEE-0747F0CDD348}} 
0 
3 

19 

False 

PhoneFax 

ACTIVITY 


40 


40 
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UnicodeCompression: 


False 


Relationships 

Table:  ACTIVITY 


ACTI VI 7YBI  LLET 

ACTIVITY 

Activityl  D 


BILLET 

oo  Activityl  D 


Attributes:  Enforced,  Cascade  Updates,  Cascade  Deletes 

RelationshipType:  One-To-Many 


Table  I  ndexes 

Name  Number  of  Fields 

PKC_ACTI  VI TY 0000  1 


Clustered: 

False 

DistinctCount: 

496 

Foreign: 

False 

IgnoreNulls: 

False 

Name: 

PKC_ACTI  VI  TY 0000 

Primary: 

True 

Required: 

True 

Unique: 

True 

Fields: 

Activityl  D 

Ascending 

UIC 

1 

Clustered: 

False 

DistinctCount: 

470 

Foreign: 

False 

IgnoreNulls: 

False 

Name: 

UIC 

Primary: 

False 

Required: 

False 

Unique: 

False 

Fields: 

UIC 

Ascending 

Table:  BILLET 

Properties 

DateCreated:  9/1/2002  7:58:13  PM 

DefauitView: 

Datasheet 

GUI  D: 

{guid  {2818B7D7-8000- 

LastUpdated: 

9/20/2002  1:58:41AM 

NameMap: 

4DFD-BA10-4D00B45F2FB3}} 
Long  binary  data 

OrderByOn: 

False 

Orientation: 

Left-to- Right 

RecordCount: 

1318 

Updatable: 

True 

Name 

Columns 

Type 

Billed  D 

Long  1  nteger 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size,  Auto- Increment 

CollatingOrder: 

General 

ColumnHidden: 

False 

Size 


4 
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ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

GUI  D: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 


Default 

Default 

False 

Primary  Key 

{guid  {6A751EE3-9760-4E88-9D62-9700BDB52654}} 
0 

True 
Billed  D 

BILLET 


Activityl  D 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnFlidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

DecimalPlaces: 

Description: 

DisplayControl: 

GUID: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 


Long  Integer  4 

False 

Fixed  Size 

General 

False 

Default 

Default 

False 

Auto 

Foreign  Key  to  ACTIVITY  table 
T ext  Box 

{guid  {085CF1D2-EAF2-4CD7-82DC-6FEB53FAAEA7}} 

1 

True 

Activityl  D 

BILLET 


BSC 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnFlidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 


Text 

True 

Variable  Length 

General 

False 

Default 

Default 

False 

Billet  Sequence  Code 
T ext  Box 


10 
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Table:  BILLET 


GUI  D: 

{guid  {13D2A66E-C2FA-4E38-A984-9315D7BCBCE4}} 

IMEMode: 

0 

IMESentenceMode: 

3 

OrdinalPosition: 

2 

Required: 

False 

SourceField: 

BSC 

SourceTable: 

BILLET 

UnicodeCompression: 

False 

PCode 

Text 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

BoundColumn: 

1 

CollatingOrder: 

General 

ColumnCount: 

2 

ColumnHeads: 

False 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

ColumnWidths: 

576:5760 

DataUpdatable: 

False 

Description: 

Billet  subspecialty  code 

DisplayControl: 

Combo  Box 

GUI  D: 

{guid  {09D93CFF-E02A-4F6B-8584-ABDD1CFD27FC}} 

IMEMode: 

0 

IMESentenceMode: 

3 

LimitToList: 

True 

ListRows: 

8 

ListWidth: 

6336twip 

OrdinalPosition: 

3 

Required: 

False 

RowSource: 

SELECT  lookupPCODE, PCode,  lookupPCODE. Description  FROM 
lookupPCODE  ORDER  BY  lookupPCODE.  1  mportance; 

RowSourceType: 

Table/Query 

SourceField: 

PCode 

SourceTable: 

BILLET 

UnicodeCompression: 

False 

PCodeSuffix 

Text 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

BoundColumn: 

1 

CollatingOrder: 

General 

ColumnCount: 

2 

ColumnFleads: 

False 

ColumnFlidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

ColumnWidths: 

288:3888 

DataUpdatable: 

False 

Description: 

Billet  subspecialty  code  suffix 

DisplayControl: 

Combo  Box 

IMEMode: 

0 

IMESentenceMode: 

3 

LimitToList: 

True 

ListRows: 

9 

ListWidth: 

4176twip 

OrdinalPosition: 

4 

Required: 

False 

RowSource: 

SELECT  lookupPCodeSuffix. PCodeSuffix, 

lookupPCodeSuffix. Description  FROM  lookupPCodeSuffix  ORDER 

BY  lookupPCodeSuffix. SortOrder; 

RowSourceType: 

Table/Query 
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SourceField: 

PCodeSuffix 

SourceTable: 

BILLET 

UnicodeCompression: 

False 

Primary  AQD 

Text 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

BoundColumn: 

1 

CollatingOrder: 

General 

ColumnCount: 

2 

ColumnFleads: 

False 

ColumnFlidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

ColumnWidths: 

432:4320 

DataUpdatable: 

False 

Description: 

Primary  billet  qualification  requirement 

DisplayControl: 

Combo  Box 

GUI  D: 

{guid  {EF6124D5-8875-43BA-90E6-FE95A4A362AE}} 

IMEMode: 

0 

IMESentenceMode: 

3 

LimitToList: 

True 

ListRows: 

8 

ListWidth: 

4752twip 

OrdinalPosition: 

5 

Required: 

False 

RowSource: 

SELECT  QUALI  FI CATI  ON.QualificationCode, 
QUALIFICATION. Description,  QUALI  FI  CATION. Importance 
FROM  QUALIFICATION  ORDER  BY 

RowSourceType: 

Table/Query 

SourceField: 

Primary  AQD 

SourceTable: 

BILLET 

UnicodeCompression: 

False 

SecondaryAQD 

Text 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

BoundColumn: 

1 

CollatingOrder: 

General 

ColumnCount: 

2 

ColumnFleads: 

False 

ColumnFlidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

ColumnWidths: 

432:4320 

DataUpdatable: 

False 

Description: 

Secondary  billet  qualification  requirement 

DisplayControl: 

Combo  Box 

GUID: 

{guid  {4269C6BE-2C0E-42E8-9F25-023DEA3FA3BE}} 

IMEMode: 

0 

IMESentenceMode: 

3 

LimitToList: 

True 

ListRows: 

8 

ListWidth: 

4752twip 

OrdinalPosition: 

6 

Required: 

False 

RowSource: 

SELECT  QUALI  FI  CATI  ON.QualificationCode, 

QUALI  FI  CATI  ON.  Description,  QUALI  FI  CATION. Importance 
FROM  QUALIFICATION  ORDER  BY 

RowSourceType: 

Table/Query 

SourceField: 

SecondaryAQD 

SourceTable: 

BILLET 
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UnicodeCompression: 

False 

Description 

Text 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

CollatingOrder: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

2520 

DataUpdatable: 

False 

Description: 

Billet  Title 

DisplayControl: 

T ext  Box 

GUI  D: 

{guid  {8B8FF8D4-A480-4A61-9BDB-09991CB9F6A4}} 

IMEMode: 

0 

IMESentenceMode: 

3 

OrdinalPosition: 

7 

Required: 

False 

SourceField: 

Description 

SourceTable: 

BILLET 

UnicodeCompression: 

False 

Rank 

Text 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

BoundColumn: 

1 

CollatingOrder: 

General 

ColumnCount: 

1 

ColumnHeads: 

False 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

ColumnWidths: 

720 

DataUpdatable: 

False 

Description: 

Billet  Rank 

DisplayControl: 

Combo  Box 

GUI  D: 

{guid  {9E338F7F-8D9C-4DF7-AC05-BB464CF66D69}} 

IMEMode: 

0 

IMESentenceMode: 

3 

LimitToList: 

True 

ListRows: 

8 

ListWidth: 

720twip 

OrdinalPosition: 

8 

Required: 

False 

RowSource: 

SELECT  lookupRANK.Rank,  lookupRANK. Importance  FROM 
lookupRANK  ORDER  BY  lookupRANK. 1  mportance; 

RowSourceType: 

Table/Query 

SourceField: 

Rank 

SourceTable: 

BILLET 

UnicodeCompression: 

False 

Designator 

Text 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

BoundColumn: 

1 

CollatingOrder: 

General 

ColumnCount: 

2 

ColumnHeads: 

False 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

ColumnWidths: 

720:5760 

DataUpdatable: 

False 

Description: 

Designator  required  by  bi 
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DisplayControl: 

GUI  D: 

IMEMode: 
IMESentenceMode: 
LimitT  oList: 
ListRows: 

ListWidth: 

OrdinalPosition: 

Required: 

RowSource: 


RowSourceType: 

SourceField: 

SourceTable: 

UnicodeCompression: 


StartDate 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnHidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 

EndDate 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnFlidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 


Relationships 
ACTI VI TYBI  LLET 

ACTIVITY 

Activityl  D 

Attributes: 

RelationshipType: 


Combo  Box 

{guid  {01C7A8AB-BF09-4E0F-8558-DAD0CBA967B4}} 

0 

3 

True 

8 

6480twip 

9 

False 

SELECT  lookupDESIGNATOR. Designator, 
lookupDESIGNATOR.  Description, 

lookupDESIGNATOR. Importance  FROM  lookupDESIGNATOR 

Table/Query 

Designator 

BILLET 

False 


Text  10 

True 

Variable  Length 

General 

False 

Default 

Default 

False 

Billet  start  date 
T ext  Box 
0 
3 

10 

False 

StartDate 

BILLET 

False 

Text  10 

True 

Variable  Length 

General 

False 

Default 

Default 

False 

Billet  end  date 
T ext  Box 
0 
3 

11 

False 

EndDate 

BILLET 

False 


BILLET 

l  °o  Activityl  D 


Enforced,  Cascade  Updates,  Cascade  Deletes 
One-To-Many 
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Bl  LLETMEMBER  BILLET 


BILLET 

BilletID 


MEMBER_  BILLET 

oo  BilletID 


Attributes:  Enforced,  Cascade  Updates,  Cascade  Deletes 

RelationshipType:  One-To-Many 


Table  I  ndexes 

Name 

ACTIVITYBILLET 

Clustered: 

DistinctCount: 

Foreign: 

IgnoreNulls: 

Name: 

Primary: 

Required: 

Unique: 

Table:  BILLET 

Fields: 

Activityl  D 

Activityl  D 

Clustered: 

DistinctCount: 

Foreign: 

IgnoreNulls: 

Name: 

Primary: 

Required: 

Unique: 

Fields: 

Activityl  D 
PKCBI LLET0002 

Clustered: 

DistinctCount: 

Foreign: 

IgnoreNulls: 

Name: 

Primary: 

Required: 

Unique: 

Fields: 

BilletID 

Table:  MEMBER 


Number  of  Fields 
1 

False 

457 

True 

False 

ACTIVITYBILLET 

False 

False 

False 


Ascending 

1 

False 

457 

False 

False 

Activityl  D 

False 

False 

False 

Ascending 

1 

False 

1318 

False 

False 

PKCBI  LLET0002 

True 

True 

True 

Ascending 


Properties 

DateCreated:  9/1/2002  7:58:13  PM 

GUI D:  {guid  (B6600329-BDBE-4117- 

944E-BBE73A5FC563}} 
NameMap:  Long  binary  data 

Orientation:  Left-to- Right 

Updatable:  True 


DefauItView: 

LastUpdated: 

OrderByOn: 

RecordCount: 


Datasheet 

9/20/2002  1:56:52  AM 

True 

1347 
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Columns 


Name 

Type  Size 

MemberlD 

Long  1  nteger 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size,  Auto- Increment 

CollatingOrder: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

Primary  Key 

GUI  D: 

{guid  {24083BE9-EFF3- 4690-9589- 5A60B376AF01}} 

OrdinalPosition: 

0 

Required: 

True 

SourceField: 

MemberlD 

SourceTable: 

MEMBER 

Designator 

Text 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

BoundColumn: 

1 

CollatingOrder: 

General 

ColumnCount: 

2 

ColumnHeads: 

False 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

ColumnWidths: 

576:5760 

DataUpdatable: 

False 

Description: 

Officer's  Designator 

DisplayControl: 

Combo  Box 

GUI  D: 

{guid  {22C55386-052A-4F01-9E7E-875DF0EEE6DC}} 

IMEMode: 

0 

IMESentenceMode: 

3 

LimitToList: 

True 

ListRows: 

8 

ListWidth: 

6336twip 

OrdinalPosition: 

1 

Required: 

False 

RowSource: 

SELECT  lookupDESIGNATOR. Designator, 
lookupDESIGNATOR.  Description, 

lookupDESIGNATOR. Importance  FROM  lookupDESIGNATOR 

RowSourceType: 

Table/Query 

SourceField: 

Designator 

SourceTable: 

MEMBER 

UnicodeCompression: 

False 

Rank 

Text 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

BoundColumn: 

1 

CollatingOrder: 

General 

ColumnCount: 

1 

ColumnHeads: 

False 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

ColumnWidths: 

720 

DataUpdatable: 

False 

Description: 

Rank 

DisplayControl: 

Combo  Box 

GUI  D: 

{guid  {88BFAC4D-CEE1-44D8-A875-EF6FD85BC05B}} 

IMEMode: 

0 

IMESentenceMode: 

3 

LimitToList: 

True 

ListRows: 

16 

120 


ListWidth: 

OrdinalPosition: 

Required: 

RowSource: 

RowSourceType: 

SourceField: 

SourceTable: 

UnicodeCompression: 


LastName 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnHidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 

FirstName 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnFlidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 

MiddleNameSuffix 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnFlidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 


720twip 

2 

False 

SELECT  lookupRANK.Rank,  lookupRANK. Importance  FROM 

lookupRANK  ORDER  BY  lookup  RANK.  I  mportance; 

Table/Query 

Rank 

MEMBER 

False 


Text  25 

True 

Variable  Length 

General 

False 

Default 

Default 

False 

Last  Name 
T ext  Box 

{guid  {E9CF0FF9-55EA-444C-98C1-9650DF13B56F}} 

0 

3 

3 

True 

LastName 

MEMBER 

False 


Text  25 

True 

Variable  Length 

General 

False 

Default 

Default 

False 

First  Name 
T ext  Box 

{guid  {6AAC0D95-1011-4C3B-BF04-F75A46F412BC}} 

0 

3 

4 

True 

FirstName 

MEMBER 

False 


Text  50 

True 

Variable  Length 

General 

False 

Default 

Default 

False 

Middle  Name  with  Suffix  (jr,  sr,  etc) 

Text  Box 

{guid  {565A4755-CF61-4AD8-A0D6-2F997ECCB858}} 

0 

3 

5 

False 

MiddleNameSuffix 

MEMBER 
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NickName 


SSN 


Ethnic 


Race 


UnicodeCompression: 

False 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

CollatingOrder: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

Nickname  if  applic 

DisplayControl: 

Text  Box 

GUI  D: 

{guid  {7C40F997- 

IMEMode: 

0 

IMESentenceMode: 

3 

OrdinalPosition: 

6 

Required: 

False 

SourceField: 

NickName 

SourceTable: 

MEMBER 

UnicodeCompression: 

False 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

CollatingOrder: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

Social  Security  Nu 

DisplayControl: 

T ext  Box 

GUI  D: 

{guid  {31DC660E 

IMEMode: 

0 

IMESentenceMode: 

3 

OrdinalPosition: 

8 

Required: 

True 

SourceField: 

SSN 

SourceTable: 

MEMBER 

UnicodeCompression: 

False 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

CollatingOrder: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

Ethnic  Group 

DisplayControl: 

Text  Box 

GUI  D: 

{guid  {0F5D4751- 

IMEMode: 

0 

IMESentenceMode: 

3 

OrdinalPosition: 

9 

Required: 

False 

SourceField: 

Ethnic 

SourceTable: 

MEMBER 

UnicodeCompression: 

False 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

CollatingOrder: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Text 


Text 


Text 


Text 


25 


9 


5 


1 
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DataUpdatable: 

Description: 

DisplayControl: 

GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 


AllowZeroLength: 

Attributes: 

BoundColumn: 

CollatingOrder: 

ColumnCount: 

ColumnHeads: 

ColumnHidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

GUI  D: 

IMEMode: 
IMESentenceMode: 
LimitT  oList: 

ListRows: 

ListWidth: 

OrdinalPosition: 

Required: 

RowSource: 

RowSourceType: 

SourceField: 

SourceTable: 

UnicodeCompression: 

YearGroup 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnFlidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 

PrecedenceNumber 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnFlidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 


False 
Race 
T ext  Box 

{guid  {D27D250B-395B-416D-B451-D888D555D470}} 
0 
3 

10 

False 

Race 

MEMBER 

False 


Text  1 

True 

Variable  Length 

1 

General 

1 

False 

False 

Default 

Default 

False 

Sex 

Combo  Box 

{guid  {B6BA6750-005D-4C24-812A-03B87E408A15}} 

0 

3 

False 

8 

Otwip 

11 

False 

M;F 

Value  List 
Sex 

MEMBER 

False 


Text  4 

True 

Variable  Length 

General 

False 

Default 

Default 

False 

Year  Group 
T ext  Box 

{guid  {BB3E459D-42A0-4D9C-BE18-458054F63C87}} 

0 

3 

12 

False 

YearGroup 

MEMBER 

False 


Text  20 

True 

Variable  Length 

General 

False 

Default 

Default 

False 
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Description: 

DisplayControl: 

GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 

PromotionStatus 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnHidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 

PCode 

AllowZeroLength: 

Attributes: 

BoundColumn: 

CollatingOrder: 

ColumnCount: 

ColumnFleads: 

ColumnFlidden: 

ColumnOrder: 

ColumnWidth: 

ColumnWidths: 

DataUpdatable: 

Description: 

DisplayControl: 

GUI  D: 

IMEMode: 

IMESentenceMode: 

LimitToList: 

ListRows: 

ListWidth: 

OrdinalPosition: 

Required: 

RowSource: 


RowSourceType: 

SourceField: 

SourceTable: 

UnicodeCompression: 


PCodeSuffix 

AllowZeroLength: 

Attributes: 

BoundColumn: 


Member's  precedence  number 
T ext  Box 

{guid  {310B719C-71CD-44C6-A45C-8EBE355E12DF}} 
0 
3 

13 

False 

PrecedenceNumber 

MEMBER 

False 


Text  6 

True 

Variable  Length 

General 

False 

Default 

Default 

False 

Member's  promotion  status 
Text  Box 

{guid  {190977A9-2E98-475C-9BFB-C76130E67647}} 

0 

3 

14 

False 

PromotionStatus 

MEMBER 

False 


Text  7 

True 

Variable  Length 

1 

General 

2 

False 

False 

Default 

Default 

720:5760 

False 

Member's  subspecialty  code 
Combo  Box 

{guid  {0B2C7A1E-AB10-44E8-8520-FC78DC82030C}} 

0 

3 

True 

8 

6480twip 

15 

False 

SELECT  lookupPCODE. PCode,  lookupPCODE. Description, 
lookupPCODE. Importance  FROM  lookupPCODE  ORDER  BY 
lookupPCODE. Importance; 

Table/Query 

PCode 

MEMBER 

False 


Text  2 

True 

Variable  Length 

1 
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CollatingOrder: 

General 

ColumnCount: 

2 

ColumnHeads: 

False 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

ColumnWidths: 

288:3888 

DataUpdatable: 

False 

Description: 

Subspecialty  code  suffix  (P,  T,  etc) 

DisplayControl: 

Combo  Box 

GUI  D: 

{guid  {D5B2C84A-C651-42F8-88D1-A5A4A14695FF}} 

IMEMode: 

0 

IMESentenceMode: 

3 

LimitT  oList: 

True 

ListRows: 

9 

ListWidth: 

4176twip 

OrdinalPosition: 

16 

Required: 

False 

RowSource: 

SELECT  lookupPCodeSuffix.PCodeSuffix, 

lookupPCodeSuffix. Description  FROM  lookupPCodeSuffix  ORDER 

BY  lookupPCodeSuffix. SortOrder; 

RowSourceType: 

Table/Query 

SourceField: 

PCodeSuffix 

SourceTable: 

MEMBER 

UnicodeCompression: 

False 

FlomeAddressl 

Text 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

CollatingOrder: 

General 

ColumnFlidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

Street  Address  Line  1 

DisplayControl: 

Text  Box 

GUID: 

{guid  {BD4B2A18-1651-4833-9752-65DF5673B1C8}} 

IMEMode: 

0 

IMESentenceMode: 

3 

OrdinalPosition: 

17 

Required: 

False 

SourceField: 

FlomeAddressl 

SourceTable: 

MEMBER 

UnicodeCompression: 

False 

FlomeAddress2 

Text 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

CollatingOrder: 

General 

ColumnFlidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

Street  Address  Line  2 

DisplayControl: 

T ext  Box 

GUID: 

{guid  {E140C7F1-D007-470D-9F63-52174658353C}} 

IMEMode: 

0 

IMESentenceMode: 

3 

OrdinalPosition: 

18 

Required: 

False 

SourceField: 

FlomeAddress2 

SourceTable: 

MEMBER 

UnicodeCompression: 

False 
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HomeCity 

Text 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

CollatingOrder: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

City 

DisplayControl: 

T ext  Box 

GUI  D: 

{guid  {915C4633-4234-4175-8020-3008F05426B3}} 

IMEMode: 

0 

IMESentenceMode: 

3 

OrdinalPosition: 

19 

Required: 

False 

SourceField: 

HomeCity 

SourceTable: 

MEMBER 

UnicodeCompression: 

False 

HomeState 

Text 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

CollatingOrder: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

State 

DisplayControl: 

T ext  Box 

GUI  D: 

{guid  {8039BC9D-772D-418D-8CC2-BB2E02F0B663}} 

IMEMode: 

0 

IMESentenceMode: 

3 

OrdinalPosition: 

20 

Required: 

False 

SourceField: 

HomeState 

SourceTable: 

MEMBER 

UnicodeCompression: 

False 

HomeZip 

Text 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

CollatingOrder: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

Zip 

DisplayControl: 

T ext  Box 

GUI  D: 

{guid  {42BFB645-3A02-456A-A93B-74FE7C244D39}} 

IMEMode: 

0 
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Table:  MEMBER 


IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 

HomeZipPlusFour 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnFiidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 

PhoneFlome 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnFiidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 

PhoneCell 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnFiidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 


3 

21 

False 

FlomeZip 

MEMBER 

False 


Text 

True 

Variable  Length 

General 

False 

Default 

Default 

False 

Zip  Plus  4 

T ext  Box 

{guid  {DBAACA0C-B9A5-448C-8214-917C5B00B607}} 
0 
3 

22 

False 

FlomeZipPlusFour 

MEMBER 

False 


Text 

True 

Variable  Length 

General 

False 

Default 

Default 

False 

Flome  phone 
T ext  Box 

{guid  {98BF08ED-E6C5-4E58-A5FB-AB25B19D9BAF}} 
0 
3 
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False 

PhoneFlome 

MEMBER 

False 


Text 

True 

Variable  Length 

General 

False 

Default 

Default 

False 

Cell  phone 
T ext  Box 

{guid  {89A989A1-45D9-47AD-AFC2-9B39B4C1CD25}} 
0 
3 

24 

False 

PhoneCell 

MEMBER 

False 


PhoneWorkComm 

Text 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

CollatingOrder: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

Commercial  phone 

DisplayControl: 

T ext  Box 

GUI  D: 

{guid  {1A288609-E377-444B-8D24-12D0A0A0BE36}} 

IMEMode: 

0 

IMESentenceMode: 

3 

OrdinalPosition: 

25 

Required: 

False 

SourceField: 

PhoneWorkComm 

SourceTable: 

MEMBER 

UnicodeCompression: 

False 

PhoneWorkCommExt 

Text 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

CollatingOrder: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

Commercial  phone  extension 

DisplayControl: 

T ext  Box 

GUI  D: 

{guid  {BC11FE94-CA2D-48F3-A4C4-1B5408EE3312}} 

IMEMode: 

0 

IMESentenceMode: 

3 

OrdinalPosition: 

26 

Required: 

False 

SourceField: 

PhoneWorkCommExt 

SourceTable: 

MEMBER 

UnicodeCompression: 

False 

PhoneWorkDSN 

Text 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

CollatingOrder: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

DSN 

DisplayControl: 

T ext  Box 

GUI  D: 

{guid  {286B697D-7D11-446F-9BBC-6A4F84C4BF39}} 

IMEMode: 

0 

IMESentenceMode: 

3 

OrdinalPosition: 

27 

Required: 

False 

SourceField: 

PhoneWorkDSN 

SourceTable: 

MEMBER 

UnicodeCompression: 

False 

PhoneWorkDSNExt 

Text 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

CollatingOrder: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

DSN  extension 
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DisplayControl: 

GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 

Pager 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnHidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 

EmailWork 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnFlidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 

EmailFlome 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnFlidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 


T ext  Box 

{guid  {211993E7-8B54-40AD-AD25-2D6E6DA1228D}} 
0 
3 

28 

False 

PhoneWorkDSNExt 

MEMBER 

False 


Text  40 

True 

Variable  Length 

General 

False 

Default 

Default 

False 

Pager 

T ext  Box 

{guid  {2294BA1D-BF61-48BF-A2FA-C82D4F21B4C1}} 

0 

3 

29 

False 

Pager 

MEMBER 

False 


Text  100 

True 

Variable  Length 

General 

False 

Default 

Default 

False 

Work  email  address 
Text  Box 

{guid  {1FAD47A5-B444-46A6-A4B5-79F3A28F5DA9}} 

0 

3 

30 

False 

EmailWork 

MEMBER 

False 


Text  100 

True 

Variable  Length 

General 

False 

Default 

Default 

False 

Flome  email  address 
Text  Box 

{guid  {68D995A1-7058-4BC2-8957-2DE7E47D1FC7}} 

0 

3 

31 

False 

EmailFlome 

MEMBER 

False 
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EmailAlternate 

Text 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

CollatingOrder: 

General 

ColumnFlidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

Alternate  email  address 

DisplayControl: 

T ext  Box 

GUI  D: 

{guid  {07890FF1-BB78-4466-92EA-E9883146E416}} 

IMEMode: 

0 

IMESentenceMode: 

3 

OrdinalPosition: 

32 

Required: 

False 

SourceField: 

EmailAlternate 

SourceTable: 

MEMBER 

UnicodeCompression: 

False 
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Relationships 

MEMBERMEMBER_BI  LLET 

MEMBER 

MemberlD 


MEMBER_  BILLET 

oo  MemberlD 


Enforced,  Cascade  Updates,  Cascade  Deletes 
One-To-Many 

Table:  MEMBER 


Attributes: 

RelationshipType: 


MEMBERMEMBER_  QUALI FICATI  ON 
MEMBER 

MemberlD  1 


MEMBER_  QUALI  FI  CA 

oo  MemberlD 


Attributes:  Enforced,  Cascade  Updates,  Cascade  Deletes 

RelationshipType:  One-To-Many 


MEMBERPREFERENCES 

MEMBER 

MemberlD 


PREFERENCES 

oo  MemberlD 


Attributes:  Enforced,  Cascade  Updates,  Cascade  Deletes 

RelationshipType:  One-To-Many 


Table  I  ndexes 

Name 


Number  of  Fields 


MemberlDLastNameFirstNameMiddleNa 

Clustered: 

DistinctCount: 

Foreign: 

IgnoreNulls: 

Name: 

Primary: 

Required: 


False 

1347 

False 

False 

MemberlDLastNameFirstNameMiddleNameSuffix 

False 

False 
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Rank 


Unique: 

False 

Fields: 

MemberlD 

Ascending 

LastName 

Ascending 

FirstName 

Ascending 

MiddleNameSuffix 

Ascending 

BER0003 

1 

Clustered: 

False 

DistinctCount: 

1347 

Foreign: 

False 

IgnoreNulls: 

False 

Name: 

PKC  MEMBER0003 

Primary: 

True 

Required: 

True 

Unique: 

True 

Fields: 

MemberlD 

Ascending 

Clustered: 

1 

False 

DistinctCount: 

12 

Foreign: 

False 

IgnoreNulls: 

False 

MBER 

Name: 

Rank 

Primary: 

False 

Required: 

False 

Unique: 

False 

Fields: 

Rank 

Ascending 

Table:  MEMBER  BILLET 


ProDerties 

DateCreated:  9/1/2002  7:58:13  PM 

DefauItView: 

Datasheet 

GUI  D: 

{guid  {F807CE2E-D659- 

LastUpdated: 

9/20/2002  2:03:00  AM 

NameMap: 

4E18-BE98-9C6A837F8F7E}} 
Long  binary  data 

OrderByOn: 

True 

Orientation: 

Left-to- Right 

RecordCount: 

1521 

Updatable: 

True 

Columns 

Name 

Type 

Size 

MemberBilletID 

Long  1  nteger 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size,  Auto- Increment 

CollatingOrder: 

General 

ColumnFlidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

Primary  Key  (Surrogate  Key) 

GUID: 

{guid  {4D055002-40C7-469B-9F91-21A902424D34}} 

OrdinalPosition: 

0 

Required: 

True 

SourceField: 

MemberBilletID 

SourceTable: 

MEMBER  BILLET 

MemberlD 

AllowZeroLength: 

Attributes: 

CollatingOrder: 


Long  I  nteger 

False 
Fixed  Size 
General 
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4 


ColumnHidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

DecimalPlaces: 

Description: 

DisplayControl: 

GUI  D: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

Billed  D 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnHidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

DecimalPlaces: 

Description: 

DisplayControl: 

GUI  D: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

ReportDate 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnHidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

PRD 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnHidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

Type 

AllowZeroLength: 


False 

Default 

Default 

False 

Auto 

Foreign  Key  from  MEMBER 
T ext  Box 

{guid  {0BA40445-5D45-44BA-BFAD-C9E73C0A6B3B}} 
1 

True 

MemberlD 

MEMBER  BILLET 


Long  Integer  4 

False 

Fixed  Size 

General 

False 

Default 

Default 

False 

Auto 

Foreign  Key  f  rom  Bl  LLET 
T ext  Box 

{guid  {CC0B45A7-5D0B-47CC-847D-65BB065BC313}} 

2 

True 
Billed  D 

MEMBER  BILLET 


Date/Time  8 

False 

Fixed  Size 

General 

False 

Default 

Default 

False 

Date  Member  Reports  for  Duty 

{guid  {8B67AF36-BEDF-4415-96AB-F53F80DFB673}} 

0 

3 

3 

False 

ReportDate 

MEMBER  BILLET 


Date/Time  8 

False 

Fixed  Size 

General 

False 

Default 

Default 

False 

Projected  Rotation  Date 

{guid  {56EF83A4-CA09-40BE-82A1-419772E9C0A6}} 

0 

3 

4 

False 

PRD 

MEMBER  BILLET 


True 


Text 


10 
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Attributes: 

Variable  Length 

BoundColumn: 

1 

CollatingOrder: 

General 

ColumnCount: 

1 

ColumnHeads: 

False 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

Type  of  Billet  (Current,  Previous,  Ultimate) 

DisplayControl: 

Combo  Box 

GUI  D: 

{guid  {C994F4B4-56AE-4762-8BE6-15E624638F85}} 

IMEMode: 

0 

IMESentenceMode: 

3 

Table:  MEMBER_BILLET 

LimitToList: 

True 

ListRows: 

8 

ListWidth: 

Otwip 

OrdinalPosition: 

6 

Required: 

True 

RowSource: 

"Previous";  "Current";  "U  Itimate" 

RowSourceType: 

Value  List 

SourceField: 

Type 

SourceTable: 

MEMBER_BILLET 

UnicodeCompression: 

False 

Relationships 

Bl  LLETMEMBER_  Bl  LLET 

BILLET 

MEMBER_  BILLET 

BilletID 

l  oo  BilletID 

Attributes: 

Enforced,  Cascade  Updates,  Cascade  Deletes 

RelationshipType: 

One-To-Many 

MEMBERMEMBER_  Bl  LLET 

MEMBER 

MemberlD 

MEMBER_  BILLET 

i  oo  MemberlD 

Attributes: 

RelationshipType: 

Enforced,  Cascade  Updates,  Cascade  Deletes 
One-To-Many 

Table  1  ndexes 

Name 

Number  of  Fields 

BILLETM  EM  BER_  BILLET 

1 

Clustered: 

False 

DistinctCount: 

1207 

Foreign: 

True 

IgnoreNulls: 

False 

Name: 

Bl  LLETMEMBER_BI  LLET 

Primary: 

False 

Required: 

False 

Unique: 

False 

Fields: 

BilletID 

Ascending 
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M  EM  BERM  EM  BER_  BILLET 
Clustered: 
DistinctCount: 
Foreign: 
IgnoreNulls: 
Name: 

Primary: 

Required: 

Unique: 

Fields: 

MemberlD 

PKC_MEMBER_BI  LLET0006 
Clustered: 
DistinctCount: 
Foreign: 
IgnoreNulls: 
Name: 

Primary: 

Required: 

Unique: 

Fields: 

MemberBilletID 


False 

1347 

True 

False 

M  EM  BERM  EM  BER_  BILLET 

False 

False 

False 

Ascending 

1 

False 

1521 

False 

False 

PKC_MEMBER_BI  LLET0006 

True 

True 

True 

Ascending 


Table:  M  EM  BER_QUALI  FI  CATION 


Properties 

DateCreated:  9/1/2002  7:58:13  PM 

GUI D:  {guid  {8DF4A080-E7B6-4922- 

9323-9472C4DA2321}} 


NameMap:  Long  binary  data 

Orientation:  Left-to- Right 

Updatable:  True 


DefauItView: 

LastUpdated: 

OrderByOn: 

RecordCount: 


Datasheet 

9/20/2002  2:04:50  AM 

False 

4322 


Columns 


Name 

MemberQualificationl  D 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnHidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

GUID: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 


Type  Size 

Long  Integer  4 

False 

Fixed  Size,  Auto- Increment 

General 

False 

Default 

Default 

False 

Primary  Key  (Surrogate  Key) 

{guid  {34F75407-C81E-4756-A7D2-F43BC4E1BBD0}} 

0 

True 

MemberQualificationl  D 
M  EM  BER_QUALI  FI  CATION 


MemberlD 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnHidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

DecimalPlaces: 

Description: 

DisplayControl: 

GUID: 


Long  Integer  4 

False 

Fixed  Size 

General 

False 

Default 

Default 

False 

Auto 

Foreign  Key  from  MEMBER  table 
T ext  Box 

{guid  {AD070369-E520-4C41-BB0F-74D529E4268F}} 
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OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 


1 

True 

MemberlD 

M  EM  BER_QUALI  FI  CATION 


Qualification!  D 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnFlidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

DecimalPlaces: 

Description: 

Table:  M  EM  BER_QUALI  FI  CATION 

DisplayControl: 

GUI  D: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 


Long  I  nteger 

False 

Fixed  Size 

General 

False 

Default 

Default 

False 

Auto 

Foreign  Key  from  QUALIFICATION  table 


T ext  Box 

{guid  {FCFE6148-E987-4587-B99B-115681EE6CA2}} 
2 

True 

Qualification!  D 
M  EM  BER_QUALI  FI  CATION 


Display 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnFlidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

Format: 

GUID: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 


Yes/No 

False 

Fixed  Size 

General 

False 

Default 

Default 

False 

Display  this  qualification  in  the  P-1? 

106 

Yes/No 

{guid  {050835CD-C374-4C05-ABBC-FCA25B3C4692}} 
3 

False 

Display 

M  EM  BER_QUALI  FI  CATION 


Order 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnFlidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

DecimalPlaces: 

Description: 

DisplayControl: 

GUID: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 


Long  I  nteger 

False 

Fixed  Size 

General 

False 

Default 

Default 

False 

Auto 

Sorting  Order 
T ext  Box 

{guid  {7D71FBB0-5C5C-463F-BC30-0EDFE79D2083}} 
4 

False 

Order 

M  EM  BER_QUALI  FI  CATION 


4 


1 


4 


Relationships 

MEMBERMEMBER_  QUALI FICATI  ON 

MEMBER  MEMBER_  QUALI  FI  CA 

MemberlD  i  °°  MemberlD 
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Attributes: 
Relationship!  ype: 


Enforced,  Cascade  Updates,  Cascade  Deletes 
One-To-Many 


Table:  M  EM  BER_QUAU  FI  CATION 


QUALI  FI  CATI  ONMEMBER_QUALI  FI  CATI  ON 


QUALI  FI  CATI  ON 

Qualification!  D 


MEMBER_  QUALI  FI  CA 

oo  Qualification!  D 


Attributes:  Enforced,  Cascade  Updates,  Cascade  Deletes 

RelationshipType:  One-To-Many 


Table  I  ndexes 

Name 

MEMBERMEMESER_QUAUFICATION 

Clustered: 

DistinctCount: 

Foreign: 

IgnoreNulls: 

Name: 

Primary: 

Required: 

Unique: 

Fields: 

MemberlD 

PKC_M  EM  BER_ QUALI  FI  CATI  ON0009 
Clustered: 

DistinctCount: 

Foreign: 

IgnoreNulls: 

Name: 

Primary: 

Required: 

Unique: 

Fields: 

MemberQualificationl  D 
QUALI  FI  CATIONMEMBER_QUALIFIC 
Clustered: 

DistinctCount: 

Foreign: 

IgnoreNulls: 

Name: 

Primary: 

Required: 

Unique: 

Fields: 

Qualification!  D 
Table:  PREFERENCES 


Number  of  Fields 
1 

False 

1214 

True 

False 

MEMBERMEMBER_QUALIFICATION 

False 

False 

False 

Ascending 

1 

False 

4322 

False 

False 

PKC_MEMBER_QUALI  FICATI  ON  0009 

True 

True 

True 

Ascending 

1 

False 

77 

True 

False 

QUALI  FI  CATIONMEMBER_QUALI  FICATI  ON 

False 

False 

False 

Ascending 


Properties 

DateCreated: 

9/1/2002  7:58:13  PM 

DefauItView: 

Datasheet 

GUI  D: 

{guid  {BE9E111D-F0AD- 
4D2E-8FF5-557B39B859FF}} 

LastUpdated: 

9/20/2002  2:07:14  AM 

NameMap: 

Long  binary  data 

OrderByOn: 

False 

Orientation: 

Left-to- Right 

RecordCount: 

0 

Updatable: 

True 

Columns 
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Name 

Preference!  D 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnHidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

GUI  D: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 


Type  Size 

Long  I  nteger 

False 

Fixed  Size,  Auto- Increment 

General 

False 

Default 

Default 

False 

Primary  Key 

{guid  {FFA39BA2-EF83-426F-9D53-1FAFAD53ADB2}} 

0 

True 

Preference!  D 

PREFERENCES 


Member!  D 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnFlidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

DecimalPlaces: 

Description: 

DisplayControl: 

GUID: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 


Long  I  nteger 

False 

Fixed  Size 

General 

False 

Default 

Default 

False 

Auto 

Foreign  Key 
T ext  Box 

{guid  {ABB979C0-73F5-43C2-9CAE-C0A0C19AE623}} 
1 

True 

MemberlD 

PREFERENCES 


DateSubmitted 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnFlidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

GUID: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 


Date/Time 

False 

Fixed  Size 

General 

False 

Default 

Default 

False 

Date  Preference  was  submitted 
{guid  {3E62BDFA-C75F-4A65-B26B-A5F03A182390}} 
0 
3 
2 

False 

DateSubmitted 

PREFERENCES 


Description 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnFlidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

GUID: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 


Text 

True 

Variable  Length 

General 

False 

Default 

Default 

False 

Description  of  preference  request 
Text  Box 

{guid  {089D8669-8B3E-446D-BB05-A0A14246C7F4}} 
0 
3 
3 

False 

Description 


SourceTable: 

UnicodeCompression: 

DetailerNotes 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnHidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 

Priority 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnHidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

DecimalPlaces: 

Description: 

DisplayControl: 

GUI  D: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 


Relationships 

MEMBERPREFERENCES 

MEMBER 

MemberlD 

Attributes: 

RelationshipType: 


Table  I  ndexes 

Name 

MEMBERPREFERENCES 

Clustered: 

DistinctCount: 

Foreign: 

IgnoreNulls: 

Name: 

Primary: 

Required: 

Unique: 

Fields: 


PREFERENCES 

False 


Text  250 

True 

Variable  Length 

General 

False 

Default 

Default 

False 

Comments  made  by  the  detailer 
Text  Box 

{guid  {DAA0F385-0BFE-416B-990A-EEADDE8AC34F}} 

0 

3 

4 

False 

DetailerNotes 

PREFERENCES 

False 


Long  Integer  4 

False 

Fixed  Size 

General 

False 

Default 

Default 

False 

Auto 

Member's  priority  assigned  to  the  preference 
T ext  Box 

{guid  {C4C04B06- 5561- 4849 -9E6A-0D9530EFEBA5}} 

5 

False 

Priority 

PREFERENCES 


PREFERENCES 

1  oo  MemberlD 


Enforced,  Cascade  Updates,  Cascade  Deletes 
One-To-Many 


Number  of  Fields 
1 

False 

0 

True 

False 

MEMBERPREFERENCES 

False 

False 

False 
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MemberlD 

PKC_PREFERENCESOOOB 

Clustered: 

DistinctCount: 

Foreign: 

IgnoreNulls: 

Name: 

Primary: 

Required: 

Unique: 

Fields: 

Preference!  D 


Ascending 

1 

False 

0 

False 

False 

PKC_PREFERENCES000B 

True 

True 

True 

Ascending 


Table:  QUALIFICATION 


Properties 

DateCreated:  9/1/2002  7:58:13  PM 

GUI  D:  {guid  {45F85DF2- D393- 

45C2-8BB6-B3830530F7E4}} 


NameMap:  Long  binary  data 

OrderByOn:  True 

RecordCount:  87 


DefauItView: 

LastUpdated: 

OrderBy: 

Orientation: 

Updatable: 


Datasheet 

9/20/2002  2:08:31AM 

QUALIFICATION. Importance 

Left-to- Right 

True 


Columns 


Name 

Type  Size 

QualifcationID 

Long  1  nteger 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size,  Auto- Increment 

CollatingOrder: 

General 

ColumnFlidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DataUpdatable: 

False 

Description: 

Primary  Key 

GUID: 

{guid  {1ED5493E-74DE-4F34-86EE-371A51268388}} 

OrdinalPosition: 

0 

Required: 

True 

SourceField: 

Qualification!  D 

SourceTable: 

QUALIFICATION 

QualificationCode 

Text 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 

CollatingOrder: 

General 

ColumnFlidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

1695 

DataUpdatable: 

False 

Description: 

Code  that  gets  imported  from  ODI S 

DisplayControl: 

T ext  Box 

GUID: 

{guid  {867818B6-37FF-4D8A-AB68-1092E280A209}} 

IMEMode: 

0 

IMESentenceMode: 

3 

OrdinalPosition: 

1 

Required: 

False 

SourceField: 

QualificationCode 

SourceTable: 

QUALIFICATION 

UnicodeCompression: 

False 

Abbreviation 

Text 

AllowZeroLength: 

True 

Attributes: 

Variable  Length 
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CollatingOrder: 

ColumnHidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 

Description 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnHidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

Description: 

DisplayControl: 

GUI  D: 

IMEMode: 

IMESentenceMode: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 

UnicodeCompression: 

Importance 

AllowZeroLength: 

Attributes: 

CollatingOrder: 

ColumnHidden: 

ColumnOrder: 

ColumnWidth: 

DataUpdatable: 

DecimalPlaces: 

Description: 

DisplayControl: 

GUI  D: 

OrdinalPosition: 

Required: 

SourceField: 

SourceTable: 


Relationships 


QUALI  FI  CATI  ON 

Qualification!  D 

Attributes: 

RelationshipType: 


General 

False 

Default 

Default 

False 

Abbreviated  translation  for  members'  codes 
T ext  Box 

{guid  {96F197EA-2764-4621-97DC-4FDF84A30D1D}} 
0 
3 
2 

False 

Abbreviation 

QUALIFICATION 

False 


Text  250 

True 

Variable  Length 

General 

False 

Default 

5280 

False 

Full  description  of  qualification 
T ext  Box 

{guid  {418E200F-F92C-461E-828B-F3C9B95A5820}} 

0 

3 

3 

False 

Description 

QUALIFICATION 

False 


Long  Integer  4 

False 

Fixed  Size 

General 

False 

Default 

Default 

False 

Auto 

Sorting  order 
T ext  Box 

{guid  {275EEAF1-F3C6-499A-A209-36281A6EC8EA}} 

4 

True 

Importance 

QUALIFICATION 


QUALI  FI  CATI  ONMEMBER_  QUALI  FI  CATI  ON 

MEMBER_  QUALI  FI  CA 

1  oo  Qualification!  D 

Enforced,  Cascade  Updates,  Cascade  Deletes 
One-To-Many 
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Table  I  ndexes 


Name 

PKC_QUAU  FI  CATI ONOOOC 
Clustered: 
DistinctCount: 
Foreign: 
IgnoreNulls: 
Name: 

Primary: 

Required: 

Unique: 

Fields: 

Qualification!  D 


Number  of  Fields 
1 

False 

87 

False 

False 

PKC_QUAU  FI  CATI  ONOOOC 

True 

True 

True 

Ascending 
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THIS  PAGE  INTENTIONALLY  LEFT  BLANK 
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APPENDIX  H:  VISUAL  BASIC  CODE 


Form:  frmACTIVITY 


Code 

1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 


VERSION  1.0  CLASS 
BEGIN 

MultiUse  =  -1  'True 
END 

Attribute  VB_  Name  =  "Form_frmACTI  VI TY" 
Attribute  VB_GlobalNameSpace  =  False 
Attribute  VB_Creatable  =  True 
Attribute  VB_  Predeclaredl  d  =  True 
Attribute  VB_  Ex  posed  =  False 
Option  Compare  Database 

Private  Sub  cmdFirstRecord_  Click( ) 

On  Error  GoTo  Err  cmdFirstRecord  Click 


DoCmd.GoToRecord , ,  acFirst 

Exit_  cmdFirstRecord_  Click: 

Exit  Sub 

Err_  cmdFirstRecord_  Click: 

MsgBox  Err.Description 
Resume  Exit_cmdFirstRecord_  Click 

End  Sub 

Private  Sub  cmdPreviousRecord_  Click( ) 

On  Error  GoTo  Err_  cmdPreviousRecord_  Click 

Dim  intResponse  As  I  nteger 
DoCmd.GoToRecord , ,  acPnevious 

Exit_  cmdPreviousRecord_  Click: 

Exit  Sub 

Err_  cmdPreviousRecord_  Click: 

intResponse  =  MsgBoxC'You  are  on  the  first  record.",  vbOKOnly) 
Resume  Exit_  cmdPreviousRecord_  Click 

End  Sub 

Private  SubcmdNextRecord_Click() 

On  Error  GoTo  Err_  cmdNextRecord_  Click 

Dim  intResponse  As  I  nteger 
DoCmd.GoToRecord , ,  acNext 

Exit_  cmdNextRecord_  Click: 

Exit  Sub 

Err  cmdNextRecord  Click: 
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Form:  frmACTIVITY 


51  intResponse  =  MsgBoxC'There  are  no  more  records.",  vbOKOnly) 

52  Resume  Exit_  cmdNextRecord_  Click 

53 

54  End  Sub 

55  Private  Sub  cmdLastRecord_  Click( ) 

56  On  Error  GoTo  Err_  cmdLastRecord_  Click 

57 

58 

59  DoCmd.GoToRecord , ,  acLast 

60 

61  Exit_cmdLastRecord_  Click: 

62  Exit  Sub 

63 

64  Err_cmdLastRecord_  Click: 

65  MsgBox  Err.Description 

66  Resume  Exit_  cmdLastRecord_  Click 

67 

68  End  Sub 

69  Private  Sub  cmdFind_Click() 

70  On  Error  GoTo  Err_  cmdFind_  Click 

71 

72 

73  Screen. PreviousControl.SetFocus 

74  DoCmd.DoMenul  tern  acFormBar,  acEditMenu,  10, ,  acMenuVer70 

75 

76  Exit_cmdFind_  Click: 

77  Exit  Sub 

78 

79  Err_cmdFind_  Click: 

80  MsgBox  Err.Description 

81  Resume  Exit_cmdFind_ Click 

82 

83  End  Sub 

84  Private  Sub  cmdNewRecord_  Click( ) 

85  On  Error  GoTo  Err_  cmdNewRecord_  Click 

86 

87 

88  DoCmd.GoToRecord  , ,  acNewRec 

89 

90  Exit_cmdNewRecord_  Click: 

91  Exit  Sub 

92 

93  Eir_  cmdNewRecord_  Click: 

94  MsgBox  Err.Description 

95  Resume  Exit_cmdNewRecord_  Click 

96 

97  End  Sub 

98  Private  Sub  cmdDeleteRecord_  Cl  ick( ) 

99  On  Error  GoTo  Err_  cmdDeleteRecord_  Click 
100 

101  Dim  intResponse  As  I  nteger 

102 

103  intResponse  =  MsgBox(  "This  will  delete  the  current  activity  and  cannot  be  undone." 

104  &  vbCr  &  "Are  you  sure  you  want  to  delete  this  activity?",  vbYesNo  _ 
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Form:  frmACTIVITY 


105  +  vbCritical  +  vbDefaultButton2,  "DELETE ACTIVITY") 

106 

107  I  f  intResponse  =  6  Then 

108  DoCmd.DoMenul  tem  acFormBar,  acEditMenu,  8, ,  acMenuVer70 

109  DoCmd.DoMenul  tem  acFormBar,  acEditMenu,  6, ,  acMenuVer70 

110  End  If 

111 
112 

113  Exit_cmdDeleteRecord_  Click: 

114  Exit  Sub 

115 

116  Err_cmdDeleteRecord_  Click: 

117  MsgBox  Err.Description 

118  Resume  Exit_cmdDeleteRecord_  Click 

119 

120  End  Sub 

121  Private  Sub  cmdPrint  ClickO 

122  On  Error  GoTo  Err_cmdPrint_  Click 

123 

124 

125  DoCmd.DoMenul  tem  acFormBar,  acEditMenu,  8, ,  acMenuVer70 

126  DoCmd. Printout  acSelection 

127 

128  Exit_cmdPrint_ Click: 

129  Exit  Sub 

130 

131  Eir_cmdPrint_  Click: 

132  MsgBox  Err.Description 

133  Resume  Exit_cmdPrint_  Click 

134 

135  End  Sub 

136 

137  Private  Sub  Form_  Current( ) 

138 

139 

140  If  Me.NewRecordThen 

141  MellblNavigate.Caption  =  "New  Record" 

142  Else 

143  With  Me.RecordsetClone 

144  .Bookmark  =  Me.  Bookmark 

145  MellblNavigate.Caption  =  "Record  "  &_ 

146  .AbsolutePosition  +  1  _ 

147  &  "  of  "  &  .RecordCount 

148  End  With 

149 

150  End  If 

151  End  Sub 

152 

153 
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Form:  frmACTIVITYBilletsSubform 


Code 

1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 


VERSION  1.0  CLASS 
BEGIN 

MultiUse  =  -1  'True 
END 

Attribute  VB_  Name  =  "Fomn_frmActivityBilletsSubform" 

Attribute  VB_GlobalNameSpace  =  False 
Attribute  VB_Creatable  =  True 
Attribute  VB_  Predeclaredl  d  =  True 
Attribute  VB_  Exposed  =  False 
Option  Compare  Database 

Private  Sub  cmdDeleteRecord_Click() 

On  Error  GoTo  Err_cmdDeleteRecord_  Click 

Dim  intResponse  As  I  nteger 

intResponse  =  MsgBoxC'This  will  delete  the  current  billet  and  cannot  be  undone." 
&  vbCr  &  "Are  you  sure  you  want  to  delete  this  billet?",  vbYesNo  _ 

+  vbCritical  +  vbDefaultButton2,  "DELETE  Bl  LLET") 

I  f  intResponse  =  6  Then 

DoCmd.DoMenultem  acFormBar,  acEditMenu,  8, ,  acMenuVer70 
DoCmd.DoMenultem  acFormBar,  acEditMenu,  6, ,  acMenuVer70 
End  If 

Exit_  cmdDeleteRecord_  Clic  k: 

Exit  Sub 

Err_  cmdDeleteRecord_  Click: 

MsgBox  Err.Description 

Resume  Exit_cmdDeleteRecord_  Click 

End  Sub 
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Form:  frmAssociateData 


1  VERSION  1.0  CLASS 

2  BEGIN 

3  Multi  Use  =  -1  'True 

4  END 

5  Attribute  VB_ Name  =  "Form_ frmAssociateData" 

6  Attribute  VB_GlobalNameSpace  =  False 

7  Attribute  VB_  Creatable  =  True 

8  Attribute  VB_  Predeclaredl  d  =  True 

9  Attribute  VB_  Exposed  =  False 

10  Option  Compare  Database 

11 

12  Private  Sub  Detail_Click() 

13  Private  Sub  c  mdAppendMemberData_  Click( ) 

14  On  Error  GoTo  Err_  cmdAppendMemberData_  Click 

15 

16  Dim  stDocName  As  String 

17  Dim  intResponse  As  I  nteger 

18 

19  intResponse  =  MsgBox(  "This  will  transfer  the  current  member  data  and  cannot  be  undone." 

20  &  vbCr  &  "Please  ensure  you  have  cleaned  up  the  data  and  are  ready  to  transfer."  _ 

21  &  vbCr  &  "Do  you  want  to  proceed  with  the  data  transfer?",  vbYesNo  _ 

22  +  vbCritical  +  vbDefaultButton2,  "TRANSFER  DATA  TO  MEMBER  TABLE") 

23 

24  I  f  intResponse  =  6  Then 

25  stDocName  =  "qryAppendtmpMemberToMEMBER" 

26  DoCmd.OpenQuery  stDocName,  acNormal,  acEdit 

27  End  If 

28 

29  Exit_  cmdAppendMemberData_  Click: 

30  Exit  Sub 

31 

32  Err_  cmdAppendMemberData_  Click: 

33  MsgBox  Err.  Description 

34  Resume  Exit_  cmdAppendMemberData_  Click 

35 

36  End  Sub 

37  End  Sub 

38  Private  Sub  cmdRun_  Click( ) 

39  On  Error  GoTo  Err_  cmdRun_  Click 

40 

41  Dim  stDocName  As  String 

42 

43  stDocName  =  "mcrAssociateBillets" 

44  DoCmd.RunMacro  stDocName 

45 

46  Exit_cmdRun_  Click: 

47  Exit  Sub 

48 

49  Err_cmdRun_  Click: 

50  MsgBox  Err.Description 

51  Resume  Exit_cmdRun_ Click 

52 

53  End  Sub 
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Form:  frmMEMBER 


Code 

1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 


VERSION  1.0  CLASS 
BEGIN 

MultiUse  =  -1  'True 
END 

Attribute  VB_  Name  =  "Fomn_  frmMEMBER" 
Attribute  VB_GlobalNameSpace  =  False 
Attribute  VB_Creatable  =  True 
Attribute  VB_  Predeclaredl  d  =  True 
Attribute  VB_  Exposed  =  False 
Option  Compare  Database 

Private  Sub  c  mdFirstRecord_  Click( ) 

On  Error  GoTo  Err  cmdFirstRecord  Click 


DoCmd.GoToRecord , ,  acFirst 

Exit_  cmdFirstRecord_  Click: 

Exit  Sub 

Err_  cmdFirstRecord_  Click: 

MsgBox  Err.Description 
Resume  Exit_cmdFirstRecord_  Click 

End  Sub 

Private  Sub  cmdPreviousRecord_  Click( ) 

On  Error  GoTo  Eir_cmdPreviousRecord_  Click 

Dim  intResponse  As  I  nteger 
DoCmd.GoToRecord , ,  acPrevious 

Exit_  cmdPreviousRecord_  Click: 

Exit  Sub 

Err_  cmdPreviousRecord_  Click: 

intResponse  =  MsgBoxC'You  are  on  the  first  record.",  vbOKOnly) 
Resume  Exit_  cmdPreviousRecord_  Click 

End  Sub 

Private  Sub  cmdNextRecord_Click() 

On  Error  GoTo  Err_cmdNextRecord_  Click 

Dim  intResponse  As  I  nteger 
DoCmd.GoToRecord , ,  acNext 

Exit_  cmdNextRecord_  Click: 

Exit  Sub 

Err  cmdNextRecord  Click: 
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Form:  frmMEMBER 

51  intResponse  =  MsgBox("There  are  no  more  records.",  vbOKOnly) 

52  Resume  Exit_  cmdNextRecord_  Click 

53 

54  End  Sub 

55  Private  Sub  cmdLastRecord_  Click( ) 

56  On  Error  GoTo  Err_cmdLastRecord_  Click 

57 

58 

59  DoCmd.GoToRecord , ,  acLast 

60 

61  Exit_cmdLastRecord_  Click: 

62  Exit  Sub 

63 

64  Err_cmdLastRecord_  Click: 

65  MsgBox  Err.Description 

66  Resume  Exit_  cmdLastRecord_  Click 

67 

68  End  Sub 

69  Private  Sub  cmdFind_Click() 

70  On  Error  GoTo  Err_  cmdFind_  Click 

71 

72 

73  Screen. PreviousControl.SetFocus 

74  DoCmd.DoMenul  tern  acFormBar,  acEditMenu,  10, ,  acMenuVer70 

75 

76  Exit_cmdFind_  Click: 

77  Exit  Sub 

78 

79  Err_cmdFind_  Click: 

80  MsgBox  Err.Description 

81  Resume  Exit_cmdFind_ Click 

82 

83  End  Sub 

84  Private  Sub  cmdNewRecord_  Click( ) 

85  On  Error  GoTo  Err_  cmdNewRecord_  Click 

86 

87 

88  DoCmd.GoToRecord  , ,  acNewRec 

89 

90  Exit_cmdNewRecord_  Click: 

91  Exit  Sub 

92 

93  Eir_  cmdNewRecord_  Click: 

94  MsgBox  Err.Description 

95  Resume  Exit_cmdNewRecord_  Click 

96 

97  End  Sub 

98  Private  Sub  cmdDeleteRecord_ Click( ) 

99  On  Error  GoTo  Err_  cmdDeleteRecord_  Click 
100 

101  Dim  intResponse  As  I  nteger 

102  Dim  frmMain  As  Form 

103  Set  frmMain  =  FormsIfrmMEMBER 

104 
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Form:  frmMEMBER 


105  intResponse  =  MsgBox( "This  will  delete  "  &  frmMain.txtRank_ 

106  &  "  "  &  frmMain.txtLastName  & "  from  the  database  and  cannot  be  undone." 

107  &  vbCr  &  "Are  you  sure  you  want  to  delete  this  record?",  vbYesNo  _ 

108  +  vbCritical  +  vbDefaultButton2,  "DELETE  SERVI CE  MEMBER") 

109 

110  If  intResponse  =  6  Then 

111  DoCmd.DoMenultem  acFormBar,  acEditMenu,  8, ,  acMenuVer70 

112  DoCmd.DoMenultem  acFormBar,  acEditMenu,  6, ,  acMenuVer70 

113  End  If 

114 

115 

116  Exit_cmdDeleteRecord_  Click: 

117  Exit  Sub 

118 

119  Err_cmdDeleteRecord_  Click: 

120  MsgBox  Err.Description 

121  Resume  Exit_cmdDeleteRecord_  Click 

122 

123  End  Sub 

124  Private  Sub  cmdPrint  ClickO 

125  On  Error  GoTo  Err_cmdPrint_  Click 

126 

127 

128  DoCmd.DoMenul  tern  acFormBar,  acEditMenu,  8, ,  acMenuVer70 

129  DoCmd. Printout  acSelection 

130 

131  Exit_cmdPrint_  Click: 

132  Exit  Sub 

133 

134  Err_cmdPrint_  Click: 

135  MsgBox  Err.Description 

136  Resume  Exit_cmdPrint_  Click 

137 

138  End  Sub 

139 

140 

141 

142 

143  Private  Sub  Fomn_  Current! ) 

144 

145  Me.  Refresh 

146 

147  If  Me.NewRecordThen 

148  MellblNavigate.Caption  =  "New  Record" 

149  Else 

150  With  Me.RecordsetClone 

151  .Bookmark  =  Me.Bookmark 

152  MellblNavigate.Caption  =  "Record  "  &_ 

153  .AbsolutePosition  +  1  _ 

154  &  "  of  "  &  .RecordCount 

155  End  With 

156 

157  End  If 

158  End  Sub 
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Form:  frmMEMBER 


159 

160 

161  Private  Sub  cmdAssignBillet_  Click( ) 

162  On  Error  GoTo  Err_cmdAssignBillet_  Click 

163 

164  Dim  stDocName  As  String 

165  Dim  stLinkCriteria  As  String 

166 

167  stDocName  =  "frmBilletAssignment" 

168 

169  stLinkCriteria  =  "[Memberl  D]="  &  Me![txtMemberi  D] 

170  DoCmd.OpenForm  stDocName, , ,  stLinkCriteria 

171 

172  Exit_cmdAssignBillet_  Click: 

173  Exit  Sub 

174 

175  Err_cmdAssignBillet_  Click: 

176  MsgBox  Err.Description 

177  Resume  Exit_cmdAssignBillet_  Click 

178 

179  End  Sub 

180  Private  Sub  cmdMbrDetails_Click() 

181  On  Error  GoTo  Err_cmdMbrDetails_  Click 

182 

183  Dim  stDocName  As  String 

184  Dim  stLinkCriteria  As  String 

185 

186  stDocName  =  "frmMemberBilletHistory" 

187 

188  stLinkCriteria  =  M[SSN]="  & . &  Me![txtSSN]  & . 

189  DoCmd.OpenForm  stDocName, , ,  stLinkCriteria 

190 

191  Exit_cmdMbrDetails_  Click: 

192  Exit  Sub 

193 

194  Err_cmdMbrDetails_  Click: 

195  MsgBox  Err.Description 

196  Resume  Exit_cmdMbrDetails_  Click 

197 

198  End  Sub 
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Form:  frmMemberBilletFlistory 


1  VERSION  1.0  CLASS 

2  BEGIN 

3  MultiUse  =  -1  'True 

4  END 

5  Attribute  VB_  Name  =  "Fomn_fmnMemberBilletHistory" 

6  Attribute  VB_GlobalNameSpace  =  False 

7  Attribute  VB_  Creatable  =  True 

8  Attribute  VB_  Predeclaredl  d  =  True 

9  Attribute  VB_  Exposed  =  False 

10  Option  Compare  Database 

11 

1 2  Private  Sub  Form_  Load( ) 

13 

14  I  f  fraPhone.  Value  =  1  Then 

15 

16  txtPhoneHome.l  nputMask  =  "1(999)  000-0000;;_" 

17  txtPhoneCell.l  nputMask  =  "1(999)  000-0000;;_" 

18  txtPhoneWorkComm.l nputMask  =  "!(999)  000-0000;; 

19 

20  Else 

21  txtPhoneHome.l  nputMask  =  "" 

22  txtPhoneCell.l  nputMask  =  "" 

23  txtPhoneWorkComm.l  nputMask  =  "" 

24 

25  End  If 

26 

27  End  Sub 

28 

29  Private  Sub  fraPhone_  Beforellpdate( Cancel  As  I  nteger) 

30 

31  If  fraPhone. Value  =  1  Then 

32 

33  txtPhoneHome.l  nputMask  =  "1(999)  000-0000;;_" 

34  txtPhoneCell.l  nputMask  =  "1(999)  000-0000;;_" 

35  txtPhoneWorkComm.l  nputMask  =  "!(999)  000-0000;; 

36 

37  Else 

38  txtPhoneHome.l  nputMask  =  "" 

39  txtPhoneCell.l  nputMask  =  "" 

40  txtPhoneWorkComm.l  nputMask  =  "" 

41 

42  End  If 

43 

44  End  Sub 

45 

46 

47  Private  Sub  cmdNewBillet_Click() 

48  On  Error  GoTo  Err_  cmdNewBillet_  Click 

49 

50  Dim  stDocName  As  String 

51  Dim  stLinkCriteria  As  String 

52 

53  stDocName  =  "frmBI  LLET" 

54  DoCmd.OpenForm  stDocName, , ,  stLinkCriteria 

55 

56  Exit_cmdNewBillet_Click: 

57  Exit  Sub 

58 

59  Err_cmdNewBillet_  Click: 

60  MsgBox  Err.Description 

61  Resume  Exit_cmdNewBillet_  Click 

62 

63  End  Sub 
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Form:  frmMemberByRank_PRD 


Code 

1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 
61 
62 
63 


VERSION  1.0  CLASS 
BEGIN 

MultiUse  =  -1  'True 
END 

Attribute  VBName  =  "Fomn_ftmMemberByRank_PRD" 

Attribute  VB_GlobalNameSpace  =  False 

Attribute  VB_Creatable  =  True 

Attribute  VB_  Predeclaredl  d  =  True 

Attribute  VB_  Exposed  =  False 

Option  Compare  Database 

Private  Sub  chkORl_Click() 

I  f  chkORl. Value  =  True  Then 
cboRank2.Visible  =  True 
lblRank2.Visible  =  True 
lblOR2.Visible  =  True 
chkOR2.Visible  =  True 

Else 

cboRank2.Visible  =  False 
lblRank2.Visible  =  False 
lblOR2.Visible  =  False 
chkOR2.Visible  =  False 
chkOR2.Value  =  False 
cboRank2.Value  =  Null 
cboRank3.Visible  =  False 
cboRank3.Value  =  Null 
lblRank3.Visible  =  False 

End  If 


End  Sub 

Private  Sub  chkOR2_Click() 

I  f  chkOR2.  Value  =  True  Then 
cboRank3.Visible  =  True 
lblRank3.Visible  =  True 
Else 

cboRank3.Visible  =  False 
lblRank3.Visible  =  False 
cboRank3.Value  =  Null 
End  If 

End  Sub 

Private  Sub  cmdOpenReport_Click() 

On  Error  GoTo  Err_  cmdOpenReport_  Click 

Dim  stDocName  As  String 

stDocName  =  "rptMemberByRank_PRD" 
DoCmd.OpenReport  stDocName,  acPreview 

Exit_  cmdOpenReport_  Click: 

Exit  Sub 

Err_  cmdOpenReport_  Click: 

MsgBox  Err.Description 

Resume  Exit_cmdOpenReport_  Click 

End  Sub 
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64  Private  Sub  Fomn_  Load( ) 

65  chkORl.Value  =  False 

66  chkOR2.Value  =  False 

67 

68  End  Sub 


Form:  frmMemberByRank_Qualification 


Code 

1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 


VERSI  ON  1.0  CLASS 
BEGIN 

MultiUse  =  -1  'True 
END 

Attribute  VB_  Name  =  "Form_frmMemberByRank_Qualification" 

Attribute  VBGIobalNameSpace  =  False 

Attribute  VB_Creatable  =  True 

Attribute  VB_  Predeclaredl  d  =  True 

Attribute  VB_  Exposed  =  False 

Option  Compare  Database 

Private  Sub  chkORl_Click() 

I  f  chkORl.Value  =  True  Then 
cboRank2.Visible  =  True 
lblRank2.Visible  =  True 
lblOR2.Visible  =  True 
chkOR2.Visible  =  True 

Else 

cboRank2.Visible  =  False 
lblRank2.Visible  =  False 
lblOR2.Visible  =  False 
chkOR2.Visible  =  False 
chkOR2.Value  =  False 
cboRank2.Value  =  Null 
cboRank3.Visible  =  False 
cboRank3.Value  =  Null 
lblRank3.Visible  =  False 

End  If 


End  Sub 

Private  Sub  chkOR2_Click() 

I  f  chkOR2.  Value  =  True  Then 
cboRank3.Visible  =  True 
lblRank3.Visible  =  True 
Else 

cboRank3.Visible  =  False 
lblRank3.Visible  =  False 
cboRank3.Value  =  Null 
End  If 

End  Sub 

Private  Sub  cmdOpenReport_Click() 

On  Error  GoTo  Err_cmdOpenReport_  Click 

Dim  stDocName  As  String 

stDocName  =  "rptMemberByRank_  Qualification" 
DoCmd.OpenReport  stDocName,  acPreview 

Exit_  cmdOpenReport_  Click: 

Exit  Sub 

Err_  cmdOpenReport_  Click: 
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59  MsgBox  Err.Description 

60  Resume  Exit_cmdOpenReport_  Click 

61 

62  End  Sub 

63 

64  Private  Sub  Form_  Load( ) 

65  chkORl.Value  =  False 

66  chkOR2.Value  =  False 

67 

68  End  Sub 

Form:  frmMemberCleanup 

Code 

1  VERSION  1.0  CLASS 

2  BEGIN 

3  MultiUse  =  -1  True 

4  END 

5  Attribute  VB_  Name  =  "Fomn_frmMemberCleanup" 

6  Attribute  VB_GlobalNameSpace  =  False 

7  Attribute  VB_  Creatable  =  True 

8  Attribute  VB_  Predeclaredl  d  =  True 

9  Attribute  VB_  Exposed  =  False 

10  Option  Compare  Database 

11 

12  Private  Sub  cmdAddBillets_  Click( ) 

13  On  Error  GoTo  Err_cmdAddBillets_  Click 

14 

15  Dim  stDocName  As  String 

16  Dim  intResponse  As  I  nteger 

17  Dim  intResponse2  As  I  nteger 

18 

19  intResponse  =  MsgBoxC'This  will  add  one  billet  for  each  instance  of  a  unique  Ul  C,BSC  liste 
here."  _ 

20  &  vbCr  &  "This  action  cannot  be  undone.  Please  ensure  you  have  cleaned  up  the  data  and 
are"_ 

21  &  "  ready  to  add  these  billets."  &  vbCr  &  "Do  you  want  to  proceed  with  the  data 
transfer?",  vbYesNo  _ 

22  +  vbCritical  +  vbDefaultButton2,  "ADD  Ml  SSI  NG  Bl  LLETS") 

23 

24  I  f  intResponse  =  6  Then 

25  stDocName  =  "qryAppendMissingBilletsFromtmpMembertotmpBI  LLET" 

26  DoCmd.OpenQuery  stDocName,  acNormal,  acEdit 

27  DoCmd.Close 

28 

29  intResponse2  =  MsgBox(  "I  f  you  have  finished  cleaning  up  all  the  member  information  "  _ 

30  &  "you  can  complete  the  process  of  importing  the  bodies  by  clicking  the  "  _ 

31  &  "Yes  button  below.  I  f  you  want  to  review  the  members  once  more,  click  No.",  vbYesNo 

32  +  vbCritical  +  vbDefaultButtonl,  "FI  NALI ZE  MEMBER  I NFORMATI  ON" ) 

33 

34  I  f  intResponse2  =  6  Then 

35  stDocName  -  "qryAppendtmpMemberToMEMBER" 

36  DoCmd.OpenQuery  stDocName,  acNormal,  acEdit 

37  Else 

38  stDocName  =  "frmMemberCleanup" 

39  DoCmd.OpenForm  stDocName,  acNormal 

40  End  If 

41 

42  End  If 

43 

44  Exit_cmdAddBillets_  Click: 

45  Exit  Sub 

46 

47  Err_cmdAddBillets_  Click: 

48  MsgBox  Err.Description 

49  Resume  Exit  cmdAddBillets  Click 
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50 

51  End  Sub 

Form:  frmProjectionDate 

Code 

1  VERSION  1.0  CLASS 

2  BEGIN 

3  MultiUse  =  -1  'True 

4  END 

5  Attribute  VB_  Name  =  "Form_ frmProjectionDate" 

6  Attribute  VB_GlobalNameSpace  =  False 

7  Attribute  VB_  Creatable  =  True 

8  Attribute  VB_  Predeclaredl  d  =  True 

9  Attribute  VB_  Exposed  =  False 

10  Option  Compare  Database 

11 

12  Private  Sub  chkProj  Date_  Click( ) 

13 

14 

15  If  chkProj  Date.  Value  =  True  Then 

16  txtProjectionDate.Visible  =  False 

17  IbIProjectionDate.Visible  =  False 

18  IblDateFormat.  Visible  =  False 

19  cmdSubmitProjectionDate.Visible  =  False 

20  cmdStaffingPlan.Visible  =  True 

21  cmdPl.Visible  =  True 

22  cmdPIBillets.Visible  =  True 

23  cmdPICommands.Visible  =  True 

24 

25  Else 

26  txtProjectionDate.Visible  =  True 

27  IbIProjectionDate.Visible  =  True 

28  cmdSubmitProjectionDate.Visible  =  True 

29  IblDateFormat.Visible  =  True 

30  cmdStaffingPlan.Visible  =  False 

31  cmdPl.Visible  =  False 

32  cmdPIBillets.Visible  =  False 

33  cmdPICommands.Visible  =  False 

34 

35  End  If 

36 

37  End  Sub 

38 

39  Private  Sub  cmdPlBillets_Click() 

40  On  Error  GoTo  Err_cmdPlBillets_  Click 

41 

42  Dim  stDocName  As  String 

43 

44  stDocName  =  "rptPl" 

45  DoCmd.OpenReport  stDocName,  acPreview 

46 

47  Exit_cmdPlBillets_  Click: 

48  Exit  Sub 

49 

50  Err_cmdPlBillets_  Click: 
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Form:  frmProjectionDate 

51  MsgBox  Err.  Description 

52  Resume  Exit_cmdPlBillets_  Click 

53  End  Sub 

54 

55  Private  Sub  cmdPlCommands_Click() 

56  On  Error  GoTo  Err_cmdPlCommands_  Click 

57 

58  Dim  stDocName  As  String 

59 

60  stDocName  =  "rptPICommandListing" 

61  DoCmd.OpenReport  stDocName,  acPreview 

62 

63  Exit_cmdPlCommands_  Click: 

64  Exit  Sub 

65 

66  Err_  cmdPlCommands_  Click: 

67  MsgBox  Err.Description 

68  Resume  Exit_cmdPlCommands_  Click 

69  End  Sub 

70 

71  Private  Sub  cmdSubmitProjectionDate_Click() 

72  On  Error  GoTo  Err_cmdSubmitProjectionDate_  Click 

73 

74  Dim  stDocName  As  String 

75  Dim  stDocName2  As  String 

76 

77  stDocName  =  "qryProjectionDateUItToCurrent" 

78  stDocName2  =  "qryUpdateDuplicateCurrentToPrevious" 

79 

80  DoCmd.OpenQuery  stDocName,  acNormal,  acEdit 

81  DoCmd.OpenQuery  stDocName2,  acNormal,  acEdit 

82  MsgBox  "Records  successfully  updated.",  vbOKOnly,  "UPDATE  SUCCESSFUL" 

83  cmdStaffingPlan.Visible  =  True 

84  cmdPl.Visible  =  True 

85  cmdPIBillets.Visible  =  True 

86  cmdPICommands.Visible  =  True 

87 

88  Exit_  cmdSubmitProj ectionDate_  Click: 

89  Exit  Sub 

90 

91  Err_  cmdSubmitProjectionDate_  Click: 

92  MsgBox  Err.Description 

93  Resume  Exit_cmdSubmitProjectionDate_Click 

94 

95  End  Sub 

96  Private  Sub  cmdStaffingPlan_  Click( ) 

97  On  Error  GoT o  Err_  cmdStaffingPlan_  Click 

98 

99  Dim  stDocName  As  String 
100 

101  stDocName  =  "rptStaffingPlan" 

102  DoCmd.OpenReport  stDocName,  acPreview 

103 

104  Exit_cmdStaffingPlan_  Click: 
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Form:  frmProjectionDate 


105  Exit  Sub 

106 

107  Err_cmdStaffingPlan_  Click: 

108  MsgBox  Err.Description 

109  Resume  Exit_cmdStaffingPlan_  Click 

110 

111  End  Sub 

112  Private  Sub cmdPl_Click() 

113  On  Error  GoTo  Err_cmdPl_  Click 

114 

115  Dim  stDocName  As  String 

116 

117  stDocName  =  "rptPICECPersonnel" 

118  DoCmd.OpenReport  stDocName,  acPreview 

119 

120  Exit_cmdPl_  Click: 

121  Exit  Sub 

122 

123  Err_cmdPl_  Click: 

124  MsgBox  Err.Description 

125  Resume  Exit_  cmdPl_  Click 

126 

127  End  Sub 


Form:  frmReviewBillets 


Code 

1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 
23 


VERSI  ON  1.0  CLASS 
BEGIN 

MultiUse  =  -1  'True 
END 

Attribute  VB_  Name  =  "Form_  frmReviewBillets" 
Attribute  VB_GlobalNameSpace  =  False 
Attribute  VB_Creatable  =  True 
Attribute  VB_  Predeclaredl  d  =  True 
Attribute  VB_  Exposed  =  False 
Private  SubcmdRefresh_Click() 

On  Error  GoTo  Err  cmdRefresh  Click 


Me.Requery 

Exit_  cmdRefresh_  Click: 

Exit  Sub 

Err_  cmdRefresh_  Click: 

MsgBox  Err.Description 
Resume  Exit_cmdRefresh_  Click 

End  Sub 
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Module:  mdIConvertDate 


Code 

1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 
27 


Attribute  VB_  Name  =  "mdIConvertDate" 

Option  Compare  Database 

Function  ConvertDate(ByVal  strDate)  As  Variant 
Takes  the  string  and  puts  it  into  proper  date  format 
On  Error  GoTo  Err_ConvertDate 

I f  Len(strDate)  =  6  Then 

strDate  =  Right( strDate,  2)  +  "/  01/  "  +  Left(strDate,  4) 

Elsel  f  strDate  =  ""  Then 
strDate  =  "" 

Elsel  f  strDate  =  "*  "  Then 
strDate  =  "" 

Else 

strDate  =  Mid(strDate,  5,  2)  +  "/  "  +  Right( strDate,  2)  +  "/  "  +  Left( strDate,  4) 
End  If 

ConvertDate  =  strDate 

Exit_  ConvertDate: 

Exit  Function 
Err_  ConvertDate: 

MsgBox  Err.  Description 
Resume  Exit  ConvertDate 


End  Function 


Module:  mdlLastDay 


Code 

1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 


Attribute  VB_ Name  -  "mdlLastDay" 

Option  Compare  Database 

Function  LastDay(ByVal  m)  As  String 

'Returns  the  last  day  of  the  month  for  a  given  month.  Leap  Years  are  not  included 
Dim  strDay  As  String 

I  f  m  =  "01"  Or  m  =  "03"  Or  m  =  "05"  Or  m  =  "07"  Or  m  =  "08"  Or  m  =  "10"  Or  m  =  "12"  Then 
strDay  =  "31" 

Elsel  f  m  =  "04"  Or  m  =  "06"  Or  m  =  "09"  Or  m  =  "11"  Then 
strDay  =  "30" 

Else 

strDay  =  "28" 

End  If 

LastDay  =  strDay 
End  Function 
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Module:  mdINameParsing 


Code 

1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 


Attribute  VB_  Name  =  "mdINameParsing" 
Option  Compare  Database 


Function  CountCSWords(ByVal  s)  As  I  nteger 
'Counts  the  words  in  a  string  that  are  separated  by  spaces. 
Dim  WC  As  I  nteger,  Pos  As  I  nteger 
IfVarType(s)  <>  8  Or  Len(s)  =  OThen 
CountCSWords  =  0 
Exit  Function 
End  If 
WC  =  1 

Pos  =  I  nStr(s,  "  ") 

Do  While  Pos  >  0 
WC  =  WC  +  1 
Pos  =  I  nStr(Pos  +  1,  s,  "  ") 

Loop 

CountCSWords  =  WC 
End  Function 

Function  GetCSWord(ByVal  s,  I  ndx  As  I  nteger) 

'Returns  the  nth  word  in  a  specific  field. 

Dim  WC  As  I  nteger,  Count  As  I  nteger 
Dim  SPos  As  I  nteger,  EPos  As  I  nteger 

WC  =  CountCSWords(s) 

I  f  I  ndx  <  1  Or  I  ndx  >  WC  Then 
GetCSWord  =  Null 
Exit  Function 
End  If 
Count  =  1 
SPos  =  1 

For  Count  =  2  To  I  ndx 
SPos  =  lnStr(SPos,  s,  "  ")  +  1 
Next  Count 

EPos  =  I  nStr(SPos,  s,  "  ")  -  1 
I  f  EPos  <  =  0  Then  EPos  =  Len(s) 

GetCSWord  =  Trim(Mid(s,  SPos,  EPos-  SPos  +  1)) 

End  Function 
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Module:  mdITitleCase 


Code 

1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 


Attribute  VB_  Name  =  "mdITitleCase" 

Option  Compare  Database 

Function  TCase(ByVal  strWord)  As  String 

'Returns  the  string  sent  in  whatever  format  to  Title  Case 

Dim  intLength  As  I  nteger 
Dim  strFirst  As  String,  strRest  As  String 
Dim  WC  As  I  nteger,  Pos  As  I  nteger 
Dim  WordCount  As  I  nteger 

If  VarType( strWord)  <>  8 Or  Len( strWord)  =  OThen 
WordCount  =  0 
Exit  Function 
End  If 
WC  =  1 

Pos  =  I  nStr( strWord,  "  ") 

Do  While  Pos  >  0 
WC  =  WC  +  1 

Pos  =  I  nStr(Pos  +  1,  strWord,  "  ") 

Loop 

WordCount  =  WC 

intLength  =  Len(  strWord) 

strFirst  =  UCase(  Left  (strWord,  1)) 

strRest  =  LCase(Right( strWord,  intLength  - 1)) 

TCase  =  strFirst  +  strRest 


End  Function 
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APPENDIX  I:  PROJECT  CD-ROM 


THE  PROJECT  CD-ROM  CAN  BE  FOUND  IN  THE  LIBRARY  COPY  OF  THIS 
THESIS.  NO  DATA  IS  STORED  IN  THE  DATABASE  ON  THIS  COPY. 
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